This page describes the trigger types available for ConductorOne automations. Each trigger determines what event causes an automation to run.
For CEL expression syntax in trigger conditions, see workflow expressions. For the full ctx.trigger object schema, see the expressions reference.
On demand (no trigger)
Use this option to create an automation that only runs when you manually execute it. This is useful for ad-hoc tasks that you need to perform on demand rather than in response to specific events or on a schedule. You can run automations without triggers from the automations list, or trigger them programmatically from other automations using the “Run automation” step.
Required fields: None (trigger is manual execution only)
Available data. What’s available in ctx.trigger depends on how the automation was started:
- Manual execution:
ctx.trigger.user_id contains the subject user selected at execution time.
- Run automation step: The full JSON context passed by the parent automation is available in
ctx.trigger.
- Requestable automation: Form field values submitted with the request are available in
ctx.trigger.form_fields.
See workflow expressions.
Example: Create a manual cleanup automation that you can run as needed to review and remove stale access
User updated
Use this trigger to respond when a user attribute changes in ConductorOne. You can monitor changes to employment status, department, manager, or any other user attribute. Add conditional expressions to narrow the trigger to specific changes, such as when a user’s status changes from “Active” to “Terminated.”
Required fields: User attribute
Optional fields: Conditional expression
Available data. Populates ctx.trigger.oldUser (User object with previous values), ctx.trigger.newUser (User object with new values), and ctx.trigger.user_id. Use ctx.trigger.oldUser and ctx.trigger.newUser to detect state transitions, for example: ctx.trigger.oldUser.department != ctx.trigger.newUser.department
Example: Trigger on a change to a user’s employment status
Account created
Use this trigger to respond when a new account is created in a specified application. This is useful for initiating onboarding workflows, sending welcome notifications, or ensuring new accounts receive appropriate access. You can add conditional expressions to refine when the trigger activates based on account properties.
Required fields: App name
Optional fields: Conditional expression
Available data. Populates ctx.trigger.newAccount (AppUser object), ctx.trigger.app_id, and ctx.trigger.user_id (the owning user). See workflow expressions.
Example: Trigger on the creation of a new GitHub account
Account updated
Use this trigger to respond when an account attribute changes in a connected application. You can monitor changes to account properties like email address, account status, role assignments, or other account-specific attributes. This helps you maintain consistency across systems or respond to important account changes.
Required fields: App name, account attribute
Optional fields: Conditional expression
Available data. Populates ctx.trigger.oldAccount (AppUser object with previous values), ctx.trigger.newAccount (AppUser object with new values), ctx.trigger.app_id, and ctx.trigger.user_id. Use the old and new values to detect changes: ctx.trigger.oldAccount.status.status != ctx.trigger.newAccount.status.status. See workflow expressions.
Example: Trigger on a change to the email address associated with an Okta account
Unused access
Use this trigger to identify when a user hasn’t logged into their app account for a specified duration. You can configure how to handle accounts with no login activity recorded and set cold start behavior to determine whether existing unused accounts are immediately processed or only newly unused accounts trigger the automation.
Required fields: App name, days since last login, cold start behavior
Optional fields: Type of account, whether to include accounts with no login activity, conditions for inclusion/exclusion
Cold start behavior: Sets whether app accounts that meet the unused access condition when you first enable the automation will immediately have the automation’s actions performed, or if the automation should proceed only after a delay. During the delay, you could alert impacted users that their access will be removed if unused.
Example: Trigger when a user hasn’t logged into GitHub for 45 days
User created
Use this trigger to respond when a new user is created in ConductorOne, typically through directory synchronization. This is ideal for initiating onboarding automations that grant initial access, send welcome communications, or create accounts in various systems. You can add conditional expressions to target specific types of new users based on their attributes.
Required fields: None
Optional fields: Conditional expression
Available data. Populates ctx.trigger.user (full User object) and ctx.trigger.user_id. See workflow expressions for field details.
Example: Trigger when a new user is created
Grant found
Use this trigger to respond when a new access grant is discovered in your environment. This is useful for monitoring when users receive new permissions, ensuring compliance with access policies, or triggering additional provisioning steps. You can filter by specific entitlements, applications, and how the grant was created (manually, through automation, via access request, etc.).
Required fields: Account type, entitlements or app name, grant source, grant type, grant origin
Available data. Populates ctx.trigger.entitlement, ctx.trigger.app_id, and ctx.trigger.user_id. See workflow expressions.
Configuration details
- Grant source: Whether the user has the grant directly or inherited it through group membership. Direct means the entitlement is assigned to the user individually; inherited means the user has it by virtue of belonging to a group.
- Grant type: Whether the grant is permanent or temporary (has an expiration date).
- Grant origin: Whether the grant was created through a ConductorOne ticket workflow or assigned directly in the external system without going through ConductorOne.
Example: Trigger when a user is granted access to the OpsGenie on-call rotation
Grant found vs. Account created. Account created fires when a new account appears in an app. Grant found fires when a new permission is discovered on an existing or new account. If you care about what access a user has (not just that they have an account), use Grant found.
Grant deleted
Use this trigger to respond when an access grant is removed from a user’s account. This helps you maintain access consistency across related systems, trigger cleanup tasks, or alert stakeholders about access removal. You can specify which types of grants to monitor based on entitlement, application, and how the grant was originally created.
Required fields: Account type, entitlements or app name, grant source, grant type, grant origin
Available data. Same fields as Grant found: ctx.trigger.entitlement, ctx.trigger.app_id, and ctx.trigger.user_id. See workflow expressions.
Example: Trigger when a user loses access to their Google Workspace account
Incoming webhook
Use this trigger to let external systems initiate ConductorOne automations by sending webhook requests. This lets you integrate ConductorOne with your broader technology ecosystem, allowing events in other systems (such as HRIS platforms, ticketing systems, or custom applications) to trigger access management workflows. You must configure authentication to ensure only authorized systems can trigger the automation.
Required fields: Authentication method (HMAC or JWT)
Available data. The webhook payload sent by the external system is available in ctx.trigger as a structured JSON object. Unlike other triggers, the subject user is not automatically resolved — you’ll need a subsequent step to look up the user from the payload data. See workflow expressions.
Example: Trigger when an employee’s status changes to Inactive in Workday
For detailed setup instructions, authentication options, code examples, and troubleshooting, see Inbound webhooks.
Schedule for user
Use this trigger to run the automation on a schedule for specified users. You can configure the frequency (daily, weekly, monthly) and select which users the automation should run for. This is useful for periodic access reviews, recurring compliance checks, or regular housekeeping tasks that you need to perform on user accounts at set intervals.
Required fields: Schedule frequency, target users
Available data. Each execution populates ctx.trigger.user_id and ctx.trigger.user for the specific user being processed. See workflow expressions.
Configuration details
Frequency options: Daily, weekly, or monthly.
Target users: Define which users the automation runs for. You can select all users or filter by user attributes. The automation executes once per matching user, so a schedule targeting 500 users produces 500 separate executions.
Example: Run a weekly access review automation for all contractors
Schedule for app user
Use this trigger to run the automation on a schedule for users of a specific application. You can configure the frequency and select which app users (or filter by account properties) the automation should run for. This is useful for app-specific maintenance tasks, periodic access validations, or recurring compliance checks on application accounts.
Required fields: Schedule frequency, app name, target app users
Available data. Each execution populates ctx.trigger.user_id, ctx.trigger.app_id, and account data for the specific app user being processed. See workflow expressions.
Configuration details
Frequency options: Daily, weekly, or monthly.
Target app users: Filter by account properties to narrow scope. The automation executes once per matching app user.
Example: Run a monthly unused access check for all Salesforce accounts
Requestable automation triggers
Requestable automations use an On demand trigger, which means they only run when a user explicitly requests them through the Actions catalog. Unlike event-based or scheduled triggers, requestable automations are initiated through a user-facing request form and governed by approval policies.
When you configure an automation as requestable, it can’t have other trigger types (such as user updated, account created, or schedule triggers). The automation remains dormant until a user submits a request, at which point it proceeds through the configured approval workflow before executing its steps.
For more information about configuring requestable automations, including how to set up request forms, approval policies, and audience scoping, see Requestable automations.
Available data. In addition to the standard On Demand context, requestable automations populate ctx.trigger.form_fields with the values submitted in the request form. For example, if the form has a “justification” text field, access it as ctx.trigger.form_fields.justification. See workflow expressions.
Subject user by trigger type
Every automation has a subject user: the person the automation is acting on. How the subject user is determined depends on the trigger:
| Trigger | Subject User | How Determined |
|---|
| On demand | Selected at execution time | Manual selection in UI, or passed via API/Run Automation step |
| User created | The newly created user | ctx.trigger.user |
| User updated | The user whose attributes changed | ctx.trigger.newUser |
| Account created | The user who owns the account | Resolved from account-to-user mapping |
| Account updated | The user who owns the account | Resolved from account-to-user mapping |
| Unused access | The user with the inactive account | Resolved from account-to-user mapping |
| Grant found | The user who received the grant | Resolved from grant-to-user mapping |
| Grant deleted | The user who lost the grant | Resolved from grant-to-user mapping |
| Incoming webhook | Depends on automation configuration | Must be resolved from webhook payload data in a subsequent step |
| Schedule for user | Each user matching the schedule criteria | Automation runs once per matching user |
| Schedule for app user | Each app user matching the criteria | Automation runs once per matching app user |
