Automation triggers reference

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

This page describes the trigger types available for C1 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 C1. 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 C1, 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 C1 ticket workflow or assigned directly in the external system without going through C1.

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 C1 automations by sending webhook requests. This lets you integrate C1 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 (system)

Use this trigger to run an automation on a recurring schedule without targeting any users. Unlike the per-user and per-app-user schedule triggers, this trigger fires once per interval regardless of your user or account population, which makes it useful for periodic reports, data syncs, or orchestration tasks that don’t act on a specific subject user.

Required fields: Schedule frequency (hourly, daily, weekly, or monthly), timezone

Optional fields: Start time

Available data. ctx.trigger is populated with the schedule context but does not include a subject user — ctx.trigger.user_id is not set. If your automation needs to act on specific users, you’ll need a subsequent step (for example, a query or search step) to resolve them. See workflow expressions.

Configuration details

Frequency options: Hourly, daily, weekly, or monthly. Monthly schedules include a day-of-month picker (1–31). Hourly schedules use only the minute field; the hour cannot be specified.

Minimum interval: Schedules must run no more frequently than once per hour. Sub-hourly specifications are rejected at validation time.

Timezone: The schedule runs in the timezone you select. Daylight Saving Time transitions are handled automatically.

Example: Run a nightly report automation at 2:00 AM to export access data to an external system

Schedule (system) vs. Schedule for user and Schedule for app user. Schedule (system) fires once per interval with no subject user. Schedule for user and Schedule for app user fire once per matching user or app user per interval. If your automation doesn’t need a per-user subject (for example, it sends a digest, runs a sync, or triggers another automation), use Schedule (system).

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 (system)	None	No subject user; resolve from automation logic if needed
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