Automation steps reference

A reference guide to all available automation steps in C1, including how to configure fields, handle errors, and reference step output in downstream steps.

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 (for example, 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 a notification to a Slack channel or as a direct message to one or more users.

Channel

Field	Required	CEL	Notes
Send to	Yes	No	Select Channel
Slack channel name	Yes	Yes	Must match an existing channel the C1 app for Slack can access
Message	Yes	Yes	Plain text. Supports template variables

Direct message

Field	Required	CEL	Notes
Send to	Yes	No	Select Direct message
Recipients	Yes	Yes	Subject user sends to the automation’s subject user. Specific users lets you select recipients by name. You can also write a CEL expression to identify recipients dynamically.
Message	Yes	Yes	Plain text. Supports template variables

Error behavior: Fails if the channel doesn’t exist or the C1 app for Slack doesn’t have access, or if a recipient doesn’t have a linked Slack account. Requires the C1 app for Slack 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 (for example, 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 (for example, 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 C1.

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 C1 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 (for example, access review, grant, revoke)
Action to take	Yes	No	The action to perform (for example, 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 C1 user data”
Additional values	Varies	Yes	Fields depend on the connector schema and creation method

Creation methods

• From C1 user data: Automatically maps the C1 user’s profile fields (name, email, department, and so on) 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 (for example, 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 C1 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.

---

Generate password

Generates a random password using either a preset 32-character random password or a custom policy.

Field	Required	CEL	Notes
Password type	Yes	No	Random 32-character password: generates a random 32-character password with no additional configuration. Custom password policy: exposes the fields below.
Length	Yes (Custom)	No	Minimum and/or maximum character length for the generated password.
Character requirements	Yes (Custom)	No	Which character types must be included: uppercase, lowercase, numbers, special characters.
Character rules	No (Custom)	No	Additional constraints on special characters: define a custom set of allowed special characters, or specify characters to exclude from the generated password.
Error behavior: Fails if the custom password policy cannot be satisfied — for example, if the required character classes cannot fit within the configured length range.

---

Set credential

This step is in early access. If you’re interested in using it, please contact the C1 Support team to request access.

Apply a credential to a user’s account in a connected application.

Set credential is only supported for self-hosted connectors. Cloud-hosted connectors do not support credential actions.

Field	Required	CEL	Notes
Connector	Yes	No	Only connectors that support credential actions appear in the picker.
Target account	Yes	Yes	The account to set the credential on. Accepts ctx.trigger.app_user_id or a CEL expression resolving to a C1 app user ID. For new accounts, pass the output of the Create account step.
Credential	Yes	No	Reference to the Generate password step output: ctx.{generate_step_name}.credential_ref.

Error behavior: Fails if the target account can’t be resolved, the account isn’t connected to the selected connector, or the connector is offline. Check the connector’s sync status on the application page if this step fails.

---

Store credential

Store a generated credential in a C1 vault and optionally deliver it to a recipient.

Field	Required	CEL	Notes
Credential	Yes	No	Reference to the Generate password step output: ctx.{generate_step_name}.credential_ref.
Vault type	Yes	No	Paper Vault: one-time secret link, self-destructs after N views or a time window. App Vault: persistent, entitlement-bound storage accessible via VaultOpenerService.
Recipient	Yes	Yes	One or more recipients. For Paper Vault, specify multiple SSO users or multiple email addresses. For App Vault, specify a single C1 user ID. Accepts a CEL expression — use ctx.trigger.user.manager_id to deliver to the subject user’s manager.
Auth type	Yes (Paper Vault)	No	How recipients authenticate to retrieve the secret. Options: SSO Internal, Email verified.
Expiry	No (Paper Vault)	No	How long the secret is available before auto-expiration. Default: 72 hours.
Max views	No (Paper Vault)	No	Number of times the secret can be viewed before it self-destructs. Default: 1.
App	Yes (App Vault)	No	The application this credential belongs to.
Entitlement	Yes (App Vault)	No	The entitlement that controls access. Users with this grant can retrieve the credential.

Error behavior: Fails if any recipient can’t be resolved. For Email verified auth type, also fails if a recipient has no email address. The step retries automatically on transient vault service errors.