> ## Documentation Index
> Fetch the complete documentation index at: https://www.c1.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# 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](/product/admin/expressions-workflows) 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 Slack app 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 Slack app doesn't have access, or if a recipient doesn't have a linked Slack account. Requires the [Slack application](/product/admin/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 (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:
```json theme={"theme":{"light":"css-variables","dark":"css-variables"}}
{
"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`:
```go theme={"theme":{"light":"css-variables","dark":"css-variables"}}
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](/product/admin/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:
```json theme={"theme":{"light":"css-variables","dark":"css-variables"}}
{
"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..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](/baton/capabilities) 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](/product/admin/functions) 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:
```go theme={"theme":{"light":"css-variables","dark":"css-variables"}}
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.`. For example, if a Function named `risk_check` returns `{ "risk_score": 8, "should_review": true }`, downstream steps can reference:
```go theme={"theme":{"light":"css-variables","dark":"css-variables"}}
ctx.risk_check.risk_score
ctx.risk_check.should_review
```
Use these in step conditions to create conditional logic:
```go theme={"theme":{"light":"css-variables","dark":"css-variables"}}
ctx.risk_check.should_review == true
```
For a full walkthrough of building Functions and using them in automations, see [using Functions in automations](/product/admin/functions-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 | C1 user ID or CEL expression. Use `ctx.trigger.user.manager_id` to deliver to the subject user's manager. |
| Auth type | Yes (Paper Vault) | No | How the recipient authenticates 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 the recipient can't be resolved. For Email verified auth type, also fails if the recipient has no email address. The step retries automatically on transient vault service errors.