Skip to main content
Use Cloudflare actions in to grant and revoke Zero Trust application access, and to look up Access groups and applications from a ticket.
See the Cloudflare setup guide to connect your account
The actions that change group membership need an API token with Edit on Access: Organizations, Identity Providers, and Groups. A read-only token can run the list and check actions only.

​
Group actions

Adds one or more users to one or more Cloudflare Access groups by appending an email include rule for each user. Users already covered by an email rule on the group are left alone.Input fields:
  • User IDs - One or more Ravenna user IDs to add (supports user groups, which are expanded to their members)
  • Cloudflare Groups - One or more Access groups to add the users to
Output data:
  • All Users Added? - True only when every user was added to every group
  • Added Users - Email addresses that were added
  • Failed Users - Email addresses that could not be added
  • Total Added - Count of added users
Common use cases:
  • Grant access to a Cloudflare-protected application after an approval
  • Assign onboarding access groups when a new hire ticket closes
  • Add a contractor to a project group for the length of an engagement
Removes one or more users from one or more Cloudflare Access groups by deleting their email include rule. Access ends when the user’s current Cloudflare session expires.Input fields:
  • User IDs - One or more Ravenna user IDs to remove (supports user groups)
  • Cloudflare Groups - One or more Access groups to remove the users from
Output data:
  • Users Removed? - True only when every user was removed from every group
  • Removed Users - Email addresses that were removed
  • Failed Users - Email addresses that could not be removed
  • Total Removed - Count of removed users
Common use cases:
  • Revoke application access during offboarding
  • Clean up temporary access when a project ticket closes
  • Remove access after an entitlement review
Checks whether a user has an email include rule on a specific Access group. Use it as a condition so a workflow does not grant access someone already has.Input fields:
  • User ID - Ravenna user ID to check
  • Cloudflare Group - The Access group to check membership against
Output data:
  • Is Member - Whether the user is a member of the group
  • User Email - The email address that was checked
  • Group ID - The group that was checked
Common use cases:
  • Skip provisioning steps for users who already have access
  • Branch a workflow on whether access needs to be requested or renewed
  • Verify a prerequisite group before granting a higher access level
Returns the name and ID of a single Access group along with the Ravenna users who are members of it.Input fields:
  • Cloudflare Group - The Access group to look up
Output data:
  • Group Found? - Whether the group was found
  • Users - Ravenna users who are members of the group
  • Group - The group’s ID and name
Common use cases:
  • Post the current membership of a group into a ticket for review
  • Notify existing members when an application changes
  • Resolve a group’s members for a downstream action
Returns every Cloudflare Access group on the account, for use in later steps of the same workflow.Output data:
  • Groups Listed? - Whether the groups were listed successfully
  • Groups - The list of Access groups
Common use cases:
  • Loop over groups to audit membership
  • Present the available groups in a request ticket
Checks whether a Ravenna user exists in Cloudflare, meaning they have authenticated through Cloudflare Access at least once.Input fields:
  • User ID - Ravenna user ID to check
Output data:
  • Is Cloudflare User - Whether the user exists in Cloudflare
Common use cases:
  • Confirm a requester is a Cloudflare Access user before granting group access
  • Route requests from users who have never signed in through Access to a human

​
Application actions

Returns the details of a single Zero Trust application.Input fields:
  • Application - The Cloudflare application to look up
Output data:
  • Application Found? - Whether the application was found
  • Application - The application’s ID, name, type, domain, and session duration
Common use cases:
  • Add the application’s domain and session duration to a ticket
  • Confirm an application exists before provisioning access to it
Returns every Zero Trust application on the account with its type and domain.Output data:
  • Applications Listed? - Whether the applications were listed successfully
  • Applications - The list of applications, each with ID, name, type, and domain
Common use cases:
  • Build an inventory of Cloudflare-protected applications
  • Loop over applications during an access review

​
Granting access after an approval

Cloudflare group membership is the mechanism behind group-based access provisioning, so most workflows follow the same shape:
1

Collect the request

A form captures which application the requester needs
2

Approve it

An approval step routes to the application owner
3

Check current access

Check Group Membership so an existing member is not processed again
4

Grant access

Add Users to Groups adds the requester to the mapped Access group
5

Tell the requester

A Slack message confirms access, noting they may need to sign in again for it to take effect
Learn more about access provisioning and approvals
Last modified on September 17, 2026