Automation steps reference

A comprehensive guide to all available automation steps in ConductorOne, including event-based, scheduled, and on-demand options.

An automation needs at least one step, and can have as many steps as you need. You can reorder steps using the arrow controls.

Each step can access data from the trigger and from previous steps using CEL expressions and the {{ }} template syntax. On the Advanced tab of each step, you’ll find the step’s Step ID, which is how downstream steps reference its output (e.g., ctx.my_step_name.field). On the Available data tab, you can browse data from previous steps. See workflow expressions for full syntax. In the field tables below:

• Required fields must be configured for the step to save.
• CEL indicates the field accepts CEL expressions or {{ }} template syntax.

---

Send email

Alerts stakeholders about important events via email.

Field	Required	CEL	Notes
Recipient	Yes	Yes	User expression or email address. Supports {{ ctx.trigger.user.email }}
Email title	Yes	Yes	Displayed as the sender name
Email subject	Yes	Yes
Email message	Yes	Yes	Rich text. Supports template variables

Error behavior: If the recipient expression resolves to an empty value or invalid email, the step fails and the automation stops.

---

Send Slack message

Posts notifications to a designated Slack channel for real-time team updates.

Field	Required	CEL	Notes
Slack channel name	Yes	Yes	Must match an existing channel the ConductorOne Slack app can access
Message	Yes	Yes	Plain text. Supports template variables

Error behavior: Fails if the channel doesn’t exist or the ConductorOne Slack app doesn’t have access. Requires the Slack application to be configured.

---

Wait for duration

Pauses the automation workflow for a specified period before continuing to the next step. Useful for giving users time to respond to notifications before taking automated action.

Field	Required	CEL	Notes
Time to wait	Yes	No	Duration value (e.g., 30 minutes, 7 days)

Error behavior: The step does not fail. The automation execution remains in a waiting state until the duration elapses, then proceeds to the next step.

If a new version of the automation is published while an execution is waiting, the waiting execution completes using the version it started with.

---

Create campaign

Automatically initiates an access review campaign from a template.

Field	Required	CEL	Notes
Access review template	Yes	No	Select from existing review templates
User whose access will be reviewed	Yes	Yes	The subject of the review

Error behavior: Fails if the review template doesn’t exist or the target user can’t be resolved.

---

Revoke entitlements

Removes specified access permissions from a user while optionally excluding certain entitlements.

Field	Required	CEL	Notes
Target user	Yes	Yes	The user whose access will be revoked
Entitlements to revoke	Yes	No	Select specific entitlements, or “all”
Entitlements to exclude	No	No	Entitlements to keep even when revoking “all”

Exclusions: When revoking “all” entitlements, use exclusions to preserve specific access (e.g., keep compliance-required archival access while revoking everything else).

Error behavior: If an entitlement doesn’t exist or the user doesn’t have it, the step skips that entitlement and continues. The step only fails if the target user can’t be resolved.

Revoking an entitlement creates a revoke task. If the app’s connector supports provisioning, the revocation is carried out automatically. Otherwise, it creates a manual task for an app owner.

---

Grant entitlements

Automatically assigns specified entitlements to a user. Commonly used in onboarding workflows.

Field	Required	CEL	Notes
Target user	Yes	Yes	The user receiving access
Entitlements to grant	Yes	No	Select one or more entitlements

Error behavior: Fails if the target user can’t be resolved or the entitlement doesn’t exist.

Granting an entitlement creates a grant task. If the app’s connector supports provisioning, the grant is carried out automatically. Otherwise, it creates a manual task for an app owner.

---

Modify delegate

Updates delegation settings for a user.

Field	Required	CEL	Notes
Target user	Yes	Yes	The user whose delegation settings will be modified

---

Remove access profiles

Unenrolls a user from one or more access profiles, stopping automatic access provisioning from those profiles.

Field	Required	CEL	Notes
Target user	Yes	Yes	The user to unenroll
Access profiles	Yes	No	Select specific profiles, or “all”

---

Modify user status

Changes a user’s account status in ConductorOne.

Field	Required	CEL	Notes
Target user	Yes	Yes	The user whose status will change
New user status	Yes	No	One of: Active, Disabled, Inactive

---

Run automation

Triggers another automation, allowing you to chain workflows together.

Field	Required	CEL	Notes
Automation name	Yes	No	The target automation (must use an On Demand trigger)
Context	No	Yes	JSON data to pass to the child automation

Passing context to child automations

The optional Context field lets you pass data from the current automation to the child. The context must be valid JSON. Use {{ }} template syntax to include dynamic values:

{
  "user_email": "{{ ctx.trigger.user.email }}",
  "department": "{{ ctx.trigger.newUser.department }}",
  "source_automation": "offboarding-v2"
}

In the child automation, access the passed context via ctx.trigger:

ctx.trigger.user_email
ctx.trigger.department

Error behavior: Fails if the target automation doesn’t exist or isn’t published. The parent automation does not wait for the child to complete; it proceeds to the next step immediately.

When debugging chained automations, check execution history on both the parent and child automations separately. The parent’s log shows that the Run Automation step succeeded (meaning it triggered the child), but you need to check the child’s execution history to see if the child’s steps succeeded.

---

Perform task action

Manages existing ConductorOne tasks by taking actions like reassigning, completing, or canceling them.

Field	Required	CEL	Notes
Whose tasks	Yes	Yes	The user whose tasks will be acted on
Task type	Yes	No	Filter by task type (e.g., access review, grant, revoke)
Action to take	Yes	No	The action to perform (e.g., reassign, complete, cancel)

---

Run webhook

Sends an HTTP request to an external system. Use this to integrate with ticketing systems, notification platforms, or custom APIs.

Field	Required	CEL	Notes
Webhook name	Yes	No	Select from configured outbound webhooks
Payload	Yes	Yes	JSON body to send. Supports {{ }} template syntax

Request format

The webhook sends an HTTP POST to the configured URL with the JSON payload as the request body. Use template syntax to include dynamic data:

{
  "ticket_type": "deprovision",
  "user_email": "{{ ctx.trigger.user.email }}",
  "apps_to_revoke": "{{ ctx.lookup_step.app_list }}",
  "requested_by": "{{ ctx.trigger.user_id }}"
}

Error behavior: Fails if the webhook returns a non-2xx HTTP status code or times out. The error details (status code, response body) are visible in the execution log.

Output data. The webhook response is available to downstream steps via ctx.<step_name>.response. This lets you act on data returned by external systems.

---

Perform connector action

Executes app-specific operations through a connector. The available actions depend on what the connector supports.

Field	Required	CEL	Notes
Connector name	Yes	No	The target connector
Action name	Yes	No	The operation to perform
Additional fields	Varies	Varies	Depends on the connector and action

Finding available actions

The actions available for each connector depend on the connector’s capabilities. When you select a connector, the action dropdown shows only the actions that connector supports. Check the connector capabilities table for an overview.

Common connector actions by app

App Type	Common Actions
Active Directory	Lock account, unlock account, reset password, disable account
Okta	Suspend user, unsuspend user, clear user sessions
Google Workspace	Suspend user, unsuspend user
AWS	Disable access keys, remove console access

The specific field requirements vary by action. After selecting an action, the step form displays the fields required for that action.

Error behavior: Fails if the connector is offline, the action is not supported, or required fields are missing. Check the connector’s sync status on the application page if this step fails.

---

Create account

Provisions a new account in a connected application.

Field	Required	CEL	Notes
Connector name	Yes	No	The target connector
Creation method	Yes	No	”Custom” or “From ConductorOne user data”
Additional values	Varies	Yes	Fields depend on the connector schema and creation method

Creation methods

• From ConductorOne user data: Automatically maps the ConductorOne user’s profile fields (name, email, department, etc.) to the target app’s account schema. Use this when the target app’s fields align with standard user attributes.
• Custom: Manually specify each field value. Use this when the target app requires fields that don’t map directly from the user profile, or when you need to compute values (e.g., generating a username from the email prefix using CEL).

Error behavior: Fails if the connector doesn’t support account creation, required fields are missing, or an account already exists for the user in the target app (behavior depends on the connector).

---

Call function

Executes a ConductorOne Function with specified input parameters, enabling custom logic and transformations within your automation.

Field	Required	CEL	Notes
Function name	Yes	No	Select from published Functions
Input parameters	Varies	Yes	Defined by the Function’s input schema. Supports CEL expressions

Passing inputs

Function input parameters are defined by the Function’s code. Use CEL expressions to pass dynamic values:

ctx.trigger.user.email        // pass the trigger user's email
ctx.trigger.form_fields.env   // pass a requestable automation form value
ctx.prev_step.some_field      // pass output from a previous step

Using function output

The Function’s return value is available to downstream steps via ctx.<step_name>. For example, if a Function named risk_check returns { "risk_score": 8, "should_review": true }, downstream steps can reference:

ctx.risk_check.risk_score
ctx.risk_check.should_review

Use these in step conditions to create conditional logic:

ctx.risk_check.should_review == true

For a full walkthrough of building Functions and using them in automations, see using Functions in automations.

Error behavior: Fails if the Function throws an unhandled error or exceeds its execution timeout. The error message from the Function is visible in the execution log. Debug Function errors in the Functions UI, which has its own invocation logs.