> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/administration-guide/ticketing/ticket-rules/triggers-and-conditions.md).

# Triggers and conditions

Every ticket rule trigger — when it fires, which ticket it shares, whether it can usefully create, update or close — and every condition the IF card offers.

## What this is, and when you need it

A ticket rule's **WHEN** card picks one or more triggers, its **IF** card narrows them with conditions. This page lists all 25 triggers — exactly when each one fires, which ticket it shares and what it is good for — and every condition. Use the [table](#what-each-trigger-can-do) to check a rule before you build it; most rules that "do nothing" use a trigger that cannot find the ticket they expect.

How the editor's cards work is on [Write a ticket rule](/administration-guide/ticketing/ticket-rules.md). Why triggers of different groups never share a ticket is on [How ticket integration works](/administration-guide/ticketing/overview.md#concept-one-ticket-per-subject).

## What each trigger can do <a href="#what-each-trigger-can-do" id="what-each-trigger-can-do"></a>

✅ works ⚠️ allowed, but rarely useful ❌ the trigger never fires

| Section              | Trigger                                                                                 | One ticket per        | Create       | Update    | Close     |
| -------------------- | --------------------------------------------------------------------------------------- | --------------------- | ------------ | --------- | --------- |
| Request lifecycle    | Request submitted                                                                       | request               | ✅ typical    | ✅         | ✅         |
|                      | Request step decided                                                                    | request               | ✅            | ✅ typical | ✅         |
|                      | Request escalated                                                                       | request               | ✅            | ✅ typical | ✅         |
|                      | Request delegated                                                                       | request               | ✅            | ✅ typical | ✅         |
|                      | Request completed                                                                       | request               | ✅            | ✅         | ✅ typical |
|                      | Request rejected                                                                        | request               | ✅            | ✅         | ✅ typical |
|                      | Request cancelled                                                                       | request               | ✅            | ✅         | ✅ typical |
|                      | Request expired                                                                         | request               | ✅            | ✅         | ✅ typical |
| People               | Access revoked                                                                          | revoke request        | ✅ typical    | ⚠️ ¹      | ⚠️ ¹      |
|                      | User created                                                                            | user                  | ✅ typical    | ⚠️ ¹      | ⚠️ ²      |
|                      | User edited                                                                             | user                  | ✅ first edit | ✅ typical | ✅ ³       |
|                      | User terminated                                                                         | user                  | ✅ typical    | ✅ ⁴       | ⚠️ ²      |
| Provisioning         | Provisioning failed                                                                     | user + managed system | ✅ typical    | ✅         | ✅         |
|                      | Provisioning succeeded                                                                  | user + managed system | ✅            | ✅         | ✅ typical |
|                      | Provisioning requested                                                                  | —                     | ❌ ⁵          | ❌ ⁵       | ❌ ⁵       |
| Non-human identities | NHI created                                                                             | identity              | ✅ typical    | ✅         | ✅         |
|                      | NHI updated, owner changed, activated, suspended, credential changed, expiring, dormant | identity              | ✅            | ✅ typical | ✅         |
|                      | NHI decommissioned, NHI deleted                                                         | identity              | ✅            | ✅         | ✅ typical |

1. The trigger is alone in its group and fires once per subject, so there is no earlier ticket to find. The rule's **If no ticket exists yet** choice decides what happens.
2. A close rule on this trigger fires on the same event that opens the ticket, so it would close the ticket at once. No later trigger can close it, because the other user triggers are separate groups.
3. Closes the user's ticket. Later edits update the closed ticket; it reopens only if a rule's transition moves it.
4. Finds a ticket only when the same user is terminated again, for example after being reactivated.
5. Reserved for a later release: no event is sent for this trigger yet.

The running example uses the typical pattern of the request lifecycle: **Request submitted → Create** (rule 1), **Request step decided → Update** (rule 2), and the four outcomes **→ Close** (rule 3).

## Request lifecycle

### Request lifecycle triggers <a href="#trigger-section-request-lifecycle" id="trigger-section-request-lifecycle"></a>

Events of an access request in OpenIAM's workflow, from submission to the outcome. All eight share one ticket per request, keyed on the OpenIAM request id. They offer the condition [Request types](#filter-request-types). Requests raised by certification workflows never emit these events, and an event without a request id is dropped.

When a request is split into one approval process per approver, each process emits its own **Request submitted** and outcome events; they all find the same ticket, so the second create follows **If a ticket already exists for this subject**.

### Request submitted <a href="#trigger-request-submitted" id="trigger-request-submitted"></a>

Fires when a request starts its approval process: access requests, new-user and termination requests, position changes and the other workflow request types. Rule 1, **Access request opened**, creates `ACCESS-142` here. The step placeholders are empty at this point.

### Request step decided <a href="#trigger-request-step-decided" id="trigger-request-step-decided"></a>

Fires when an approver approves or rejects one step. `${decision}` is `approved` or `rejected`, `${step.name}`, `${step.comment}` and the approver placeholders describe the step. Use it with **Update** to comment on the request's ticket, as rule 2 does.

### Request completed <a href="#trigger-request-completed" id="trigger-request-completed"></a>

Fires when the request has been approved and its entitlements are accepted — the end of a successful request. The typical close trigger.

### Request rejected <a href="#trigger-request-rejected" id="trigger-request-rejected"></a>

Fires when the request is rejected. Combine it with the other outcomes in one close rule.

### Request cancelled <a href="#trigger-request-cancelled" id="trigger-request-cancelled"></a>

Fires when the requester or an administrator cancels the request. The step placeholders describe the task that was open.

### Request expired <a href="#trigger-request-expired" id="trigger-request-expired"></a>

Fires when an approval task expires without a decision. There is no initiator: `${actor.displayName}` is empty. If the flow then rejects the request, a **Request rejected** event follows; a close rule on both finds the ticket already closed the second time.

### Request escalated <a href="#trigger-request-escalated" id="trigger-request-escalated"></a>

Fires when an approval task is escalated. A comment rule here tells the service desk who holds the task now.

### Request delegated <a href="#trigger-request-delegated" id="trigger-request-delegated"></a>

Fires when an approver delegates a task to someone else. An automatic delegation to an alternate contact does not emit it.

## People

### People triggers <a href="#trigger-section-people" id="trigger-section-people"></a>

Events of a user's record and of revoke requests. Each trigger here is its own trigger group, so a rule takes exactly one of them, and a ticket opened by one is never found by another.

### Access revoked <a href="#trigger-access-revoked" id="trigger-access-revoked"></a>

Fires when a revoke request removes access — the revoke-access workflow and the workflows that remove a user from a role, group or organization or take a resource entitlement away. One ticket per revoke request. Offers the condition [Resources](#filter-resources). Use it with **Create**.

### User created <a href="#trigger-user-created" id="trigger-user-created"></a>

Fires after a new user is saved, however it was created: in the Webconsole, by a request, by a synchronization. No conditions. One ticket per user that no later trigger finds — a good fit for "prepare a desk for the new hire".

### User edited <a href="#trigger-user-edited" id="trigger-user-edited"></a>

Fires after a user is saved with at least one real change. Saves that only change bookkeeping (audit timestamps, password and challenge dates, the first-login flag and similar) do not fire it. The changes include the user's own fields, `emailAddresses`, `phones`, `addresses`, `supervisors` and the names of changed user attributes; [Changed attributes](#filter-changed-attributes) filters on them and `${changedAttributes}` lists them. One ticket per user for all of that user's edits.

A save that moves the user into a terminated status fires **User terminated** instead, even if other fields changed in the same save.

### User terminated <a href="#trigger-user-terminated" id="trigger-user-terminated"></a>

Fires when a save moves the user from an active status into one of `TERMINATED`, `DEACTIVATED`, `DECEASED`, `LEAVE`, `LEAVE_WITH_PAY` or `LEAVE_OF_ABSENCE`. A move between two of these (from leave to terminated) is an edit, not a termination. No conditions. Rule 5, **Leaver equipment return**, opens `SCTASK0010042` for Alex Morgan here.

## Provisioning

### Provisioning triggers <a href="#trigger-section-provisioning" id="trigger-section-provisioning"></a>

The outcome of provisioning to a managed system, read from the connector's reply. **Provisioning failed** and **Provisioning succeeded** share one ticket per user and managed system. They are emitted for user save, delete, reset password, suspend and resume, and for group save and delete. Conditions: [Managed systems](#filter-managed-systems) and [Operations](#filter-operations).

For a group, the subject is the group and the managed system, and the user placeholders (**Target user**, **Manager**) are empty.

### Provisioning failed <a href="#trigger-provisioning-failed" id="trigger-provisioning-failed"></a>

Fires when the managed system reports the operation failed. `${error.message}` holds the connector's error. Rule 4, **Provisioning failure**, creates a High-priority ticket for failures on Corporate AD. A provisioning that never gets a reply (an asynchronous time-out) emits nothing.

### Provisioning succeeded <a href="#trigger-provisioning-succeeded" id="trigger-provisioning-succeeded"></a>

Fires when the managed system reports success. Pair it with **Provisioning failed** in a close rule to close the failure ticket once a retry succeeds.

### Provisioning requested <a href="#trigger-provisioning-requested" id="trigger-provisioning-requested"></a>

Reserved for a later release; no event is sent for it. It belongs to the Fulfilment group, so the editor does not let you combine it with the other two.

## Non-human identities

### NHI triggers <a href="#trigger-section-nhi" id="trigger-section-nhi"></a>

Events of a [non-human identity](/administration-guide/nhi.md) — a service account, an API key, a bot, a certificate. All ten share one ticket per identity. Conditions: [NHI types](#filter-nhi-types), [Environments](#filter-environments) and [Risk classifications](#filter-risk-classifications). The NHI placeholders are filled from a snapshot taken when the event happened, so they stay right even for a deleted identity.

### NHI created <a href="#trigger-nhi-created" id="trigger-nhi-created"></a>

Fires when a non-human identity is registered. The typical create trigger of the group.

### NHI updated <a href="#trigger-nhi-updated" id="trigger-nhi-updated"></a>

Fires when the identity is changed or rescoped.

### NHI owner changed <a href="#trigger-nhi-owner-changed" id="trigger-nhi-owner-changed"></a>

Fires when the identity gets a new owner. `${nhi.previousOwner.displayName}` names the previous one.

### NHI activated <a href="#trigger-nhi-activated" id="trigger-nhi-activated"></a>

Fires when the status changes to Active. `${nhi.fromStatus}` and `${nhi.toStatus}` hold both statuses. A change to Draft or Pending emits nothing.

### NHI suspended <a href="#trigger-nhi-suspended" id="trigger-nhi-suspended"></a>

Fires when the status changes to Suspended.

### NHI decommissioned <a href="#trigger-nhi-decommissioned" id="trigger-nhi-decommissioned"></a>

Fires when the status changes to Decommissioned. A typical close trigger.

### NHI deleted <a href="#trigger-nhi-deleted" id="trigger-nhi-deleted"></a>

Fires just before the identity is deleted. Nothing later can find its ticket, so close it here.

### NHI credential changed <a href="#trigger-nhi-credential-changed" id="trigger-nhi-credential-changed"></a>

Fires when a credential of the identity is created, rotated, updated or deleted; `${credential.operation}` says which. The credential placeholders are available only for this trigger.

### NHI expiring <a href="#trigger-nhi-expiring" id="trigger-nhi-expiring"></a>

Fires 30, 14 and 7 days before the identity expires, from the scheduled governance check. All three events share the identity's ticket: a create rule opens it at 30 days, and an update rule can comment at 14 and 7.

### NHI dormant <a href="#trigger-nhi-dormant" id="trigger-nhi-dormant"></a>

Fires when the governance check finds the identity unused for longer than its dormancy threshold.

## Conditions <a href="#conditions" id="conditions"></a>

The **IF · Applies to** card offers the condition fields of the selected triggers. Every field holds a list of values and matches an event whose value is *any* of them. An empty field does not restrict. Conditions in different fields must all match. There are no other operators: no "not", no "contains", no wildcards. A condition matches nothing when the event carries no value for it — a **Managed systems** condition never matches a request event.

### Request types <a href="#filter-request-types" id="filter-request-types"></a>

Request lifecycle triggers. Matches the request's workflow type, the names the field suggests (the request types defined in your workflows). Case-sensitive.

### Changed attributes <a href="#filter-changed-attributes" id="filter-changed-attributes"></a>

**User edited** only. Fires when at least one listed name is among the save's changes. Suggestions are the 43 user fields and then your custom user attributes; `emailAddresses`, `phones`, `addresses` and `supervisors` stand for the contact collections. Case-sensitive: use the suggested names.

### Resources <a href="#filter-resources" id="filter-resources"></a>

**Access revoked** only. Limits the rule to revoke requests for the chosen resources. Picked by name.

### Managed systems <a href="#filter-managed-systems" id="filter-managed-systems"></a>

Provisioning triggers. Limits the rule to provisioning on the chosen managed systems — rule 4 uses Corporate AD. Picked by name.

### Operations <a href="#filter-operations" id="filter-operations"></a>

Provisioning triggers. Limits the rule to the listed operations: `SAVE`, `DELETE`, `RESET_PASSWORD`, `SUSPEND`, `RESUME`. Case-sensitive.

### NHI types <a href="#filter-nhi-types" id="filter-nhi-types"></a>

NHI triggers. Service Account, API Key / Token, CI/CD Pipeline, RPA / Bot, Certificate / PKI, Cloud Workload, AI Agent, Workforce-Spawned Credential.

### Environments <a href="#filter-environments" id="filter-environments"></a>

NHI triggers. The identity's environment, such as `DEV`, `TEST`, `STAGING` or `PROD`, compared ignoring case.

### Risk classifications <a href="#filter-risk-classifications" id="filter-risk-classifications"></a>

NHI triggers. `LOW`, `MEDIUM`, `HIGH` or `CRITICAL`, compared ignoring case.

### Triggers with no conditions <a href="#filter-none" id="filter-none"></a>

**User created** and **User terminated** offer no conditions: *People triggers have no extra conditions: the rule applies to every event of the trigger.* A rule on them raises a ticket for every new user or every leaver; to raise tickets only for some, route them through a request (a new-user or termination request) and use **Request types** instead.

## When it goes wrong

| Symptom                                                               | Likely cause                                                                  | Resolution                                                                            |
| --------------------------------------------------------------------- | ----------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- |
| A rule on **Provisioning requested** never fires                      | The trigger is reserved                                                       | Use **Provisioning failed** or **Provisioning succeeded**                             |
| A **User terminated → Close** rule never closes the onboarding ticket | **User created** and **User terminated** are different groups                 | Close onboarding tickets in the ticketing system, or open them from a request instead |
| A **User edited** rule fires on every save of a user                  | No **Changed attributes** condition                                           | Add the attributes that matter                                                        |
| A **User edited** rule with conditions never fires                    | A typo or wrong case in **Changed attributes**                                | Pick the names from the suggestions                                                   |
| A request rule fires for every request type                           | **Request types** is empty                                                    | Add the request types                                                                 |
| A request rule never fires for one kind of request                    | The request comes from a certification workflow, or is not a workflow request | Use a user or provisioning trigger instead                                            |
| Two outcome events arrive for one expired request                     | The expiry rejected the request too                                           | Expected; the second close finds the ticket already closed                            |
| A group provisioning ticket has empty user details                    | Group events carry no target user                                             | Use `${managedSystem.name}`, `${operation}` and `${error.message}`                    |

## Related

* [Write a ticket rule](/administration-guide/ticketing/ticket-rules.md) — the WHEN and IF cards.
* [How ticket integration works](/administration-guide/ticketing/overview.md) — trigger groups and subjects.
* [Template placeholders](/administration-guide/ticketing/ticket-rules/placeholders.md) — what each trigger can fill.
* [Manage non-human identities](/administration-guide/nhi.md) — the identities behind the NHI triggers.
* [Approval flows](/administration-guide/requests/approval-flows.md) — where the request lifecycle events come from.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.openiam.com/administration-guide/ticketing/ticket-rules/triggers-and-conditions.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.