Skip to main content
Each automation can be triggered by an event such as the creation of a new application account or a change in a user or account’s status. You can also skip adding a trigger and run the automation manually instead.

​
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) 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 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 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 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 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 Example: Trigger when a user is granted access to the OpsGenie on-call rotation

​
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 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 (like 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) Example: Trigger when an employee’s status changes to Inactive in Workday

​
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 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 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 the requestable automations documentation.