NEEDS REVIEW Add access conflict trigger to automation triggers reference

product/admin/automations-triggers-reference.mdx

@@ -4,13 +4,13 @@
 sidebarTitle: "Automation triggers"
 ---
 
 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](/product/admin/expressions-workflows). For the full `ctx.trigger` object schema, see the [expressions reference](/product/admin/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)
 
@@ -18,7 +18,7 @@
 
 - **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](/product/admin/expressions-workflows).
 
@@ -58,7 +58,7 @@
 
 **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](/product/admin/expressions-workflows).
 
 **Example:** Trigger on a change to the email address associated with an Okta account
 
 ### Unused access
 
@@ -74,7 +74,7 @@
 
 ### 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
 
@@ -116,7 +116,7 @@
 
 ### 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)
 
@@ -143,6 +143,39 @@
 
 **Example:** Run a weekly access review automation for all contractors
 
+### Access conflict
+
+Use this trigger to respond when a [conflict monitor](/product/admin/access-conflicts) detects new separation of duties (SoD) violations. This lets you build automated remediation workflows — for example, creating tickets in external systems like Jira, notifying security teams, or initiating access reviews when incompatible access is detected.
+
+**Required fields:** Conflict monitor selection (all monitors or specific monitors)
+
+**Available data.** Populates the following fields in `ctx.trigger`:
+
+- `conflictMonitorId` — the ID of the conflict monitor that detected the violations
+- `conflictMonitorDisplayName` — the monitor's display name
+- `identityUserId` — the ConductorOne user ID of the user with conflicting access
+- `identityUserDisplayName` — the user's display name
+- `identityUserEmail` — the user's email address
+- `violationIds` — list of violation IDs detected for this user
+- `violationCount` — number of violations detected
+- `violationDetails` — list of violation objects, each containing:
+  - `violationId` — the violation ID
+  - `groupAAppDisplayName` — the application name for the first conflicting entitlement
+  - `groupAAppEntitlementDisplayName` — the display name of the first conflicting entitlement
+  - `groupBAppDisplayName` — the application name for the second conflicting entitlement
+  - `groupBAppEntitlementDisplayName` — the display name of the second conflicting entitlement
+
+See [workflow expressions](/product/admin/expressions-workflows).
+
+#### Configuration details
+
+- **All conflict monitors**: The automation triggers whenever any conflict monitor detects a new violation.
+- **Specific conflict monitors**: Select up to 32 monitors. The automation only triggers for violations detected by the selected monitors.
+
+The automation fires once per affected user per monitor run. If a user has multiple violations from the same monitor, they are grouped into a single trigger execution.
+
+**Example:** Trigger when a conflict monitor detects that a user has incompatible entitlements, then use a Function step to create a Jira ticket with the violation details for remediation tracking
+
 ### 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.
@@ -160,15 +193,15 @@
 
 **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](/product/admin/automation-actions).
 
 **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](/product/admin/expressions-workflows).
 
 ## Subject user by trigger type
 
@@ -185,6 +218,7 @@
 | 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 |
+| Access conflict | The user with conflicting access | `ctx.trigger.identityUserId` |
 | 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 |