> 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.md). # Ticket integration with Jira and ServiceNow Ticket integration — OpenIAM opens, updates and closes tickets in Jira or ServiceNow when requests, users, provisioning or non-human identities change, and reads their status back. ## What this is, and when you need it OpenIAM 2026.10.2 can raise tickets in **Jira** (Cloud or Data Center) or **ServiceNow** on its own. You connect the ticketing system as a managed system, write **ticket rules** that say which OpenIAM event opens, updates or closes a ticket and what the ticket says, and OpenIAM does the rest: it keeps one ticket per subject, retries a delivery the ticketing system did not accept, reads the ticket's status back every 15 minutes, and shows every ticket and its audit trail on one screen. Requesters and approvers see the ticket next to their request in SelfService. Read this section when a service desk has to know about something OpenIAM does — an access request waiting for a manual step, a leaver whose laptop must be collected, a provisioning failure someone must fix, a service account about to expire. If a connector can make the change in the target system itself, provision instead; a ticket asks a person to do the work. It replaces the Groovy script hook described in [Raise a ServiceNow incident from an approval](/administration-guide/requests/approval-flows/raise-a-servicenow-incident.md). That hook still runs in 2026.10.2 but is deprecated; [Operate ticket integration](/administration-guide/ticketing/operate-ticketing.md#operate-migrate-from-the-groovy-hook) says how to move off it. ## Start here | If you are… | Read | | --------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Anyone who has just heard of ticket integration | [How ticket integration works](/administration-guide/ticketing/overview.md) — events, rules, one ticket per subject, delivery states. No settings | | Connecting Jira or ServiceNow | [Connect a ticketing system](/administration-guide/ticketing/connect-a-ticketing-system.md) — the connector, the managed system, the credentials, Test connection | | Writing your first rule | [Write a ticket rule](/administration-guide/ticketing/ticket-rules.md) — the rules list and the four cards of the rule editor | | Choosing which event fires a rule | [Triggers and conditions](/administration-guide/ticketing/ticket-rules/triggers-and-conditions.md) — every trigger, what it can create, update or close, and the conditions it offers | | Filling the ticket with details | [Template placeholders](/administration-guide/ticketing/ticket-rules/placeholders.md) — every `${…}` placeholder and the triggers that can fill it | | Checking how a field lands in your system | [How fields reach Jira and ServiceNow](/administration-guide/ticketing/jira-and-servicenow.md) — projects and tables, priorities, labels, transitions, additional fields | | Watching what was sent | [Track tickets](/administration-guide/ticketing/tickets.md) — the Tickets screen, the ticket details, retry and discard, the SelfService Ticket column | | Adding a field to every ticket, or reading status back | [The TICKET policy map and ticket synchronization](/administration-guide/ticketing/policy-map-and-sync.md) | | Trying rules out before anything reaches the service desk | [Review tickets before they are sent](/administration-guide/ticketing/review-before-sending.md) — simulation mode for tickets | | Running the integration | [Operate ticket integration](/administration-guide/ticketing/operate-ticketing.md) — delivery and retries, every property, the audit actions, troubleshooting, the move from the Groovy hook | ## Where it lives Everything is on the managed system that represents the ticketing system, in the Webconsole: | Screen | Path | Route | | ---------------------------- | -------------------------------------------------- | ----------------------------------------------------------- | | The ticketing managed system | **Provisioning → Managed System**, open the system | `/webconsole/mngsystem` | | Ticket rules | The managed system's menu → **Ticket rules** | `/webconsole/ticket-rules?id=` | | Rule editor | **Ticket rules → New rule**, or a rule's edit icon | `/webconsole/ticket-rule?id=&ruleId=` | | Tickets | The managed system's menu → **Tickets** | `/webconsole/tickets?id=` | | TICKET policy map | The managed system's menu → **Policy map** | `/webconsole/policyMap?id=` | | Simulation | The managed system's menu → **Simulation** | `/webconsole/simulation` | **Ticket rules** and **Tickets** appear only on a managed system whose connector is the Ticket Connector; on such a system the reconciliation menu items are hidden instead, because a ticketing system has no accounts to reconcile. In SelfService the only ticket surface is the **Ticket** column of the task and request lists and the ticket line in a task's details. There is nothing to configure there. ## The example that runs through every page The same two ticketing systems and five rules appear on every page, so the names and values agree from one page to the next. All people are fictitious. * **Service Desk Jira** — a Jira Cloud site at `https://example-corp.atlassian.net`, signed in as `openiam-integration@example-corp.com` with an API token. Tickets go to the project **ACCESS** (*Access Requests*) as issue type **Task**. 1. **Access request opened** — **Request submitted** → **Create**, priority **Medium**, label `access-request`, summary `Access request ${request.name} for ${targetUser.displayName}`, and a description listing `${request.justification}` and `${request.items}`. 2. **Access request decided** — **Request step decided** → **Update**, comment `${step.approver.displayName} decided ${decision} on ${step.name}: ${step.comment}`. 3. **Access request finished** — **Request completed**, **Request rejected**, **Request cancelled** and **Request expired** → **Close** with the transition **Done** and the closing comment `Request ${request.status}.`; if no ticket exists yet, **Do nothing and log**. 4. **Provisioning failure** — **Provisioning failed**, only for the managed system **Corporate AD** → **Create**, priority **High**, summary `${operation} of ${targetUser.login} failed on ${managedSystem.name}`. * **IT Service Desk** — a ServiceNow instance at `https://example-corp.service-now.com`, signed in as the integration user `openiam.integration`. 5. **Leaver equipment return** — **User terminated** → **Create** on the table `sc_task`, priority `3 - Moderate`, summary `Collect equipment from ${targetUser.displayName}`. Jordan Lee requests *Finance Reports* access for Sam Patel; Priya Nair approves the step. Rule 1 opens **ACCESS-142**, rule 2 comments on it, rule 3 closes it. When Alex Morgan leaves, rule 5 opens **SCTASK0010042** in ServiceNow. ## Files in this folder that are not articles * `anchors.json` maps product UI elements to the sections here. It is a build input for the frontend's "book icon" deep links, so editing it is a product change. The entry shape and the anchor naming convention are in `_FRONTEND-WIRING.md`, which also says what the frontend still has to do before the icons render for this section. * `_OPEN-QUESTIONS.md` lists what could not be confirmed when these pages were written, what was described from an unmerged branch, and the product gaps the pages describe as they are. * `_screenshots/ticketing-shot-list.md` lists the screenshots the pages are written to carry, with file names and alt text, for whoever captures them. None of the three is listed in `SUMMARY.md`. ## Related * [Connectors and managed systems](/administration-guide/lifecycle/connectors-and-managed-systems.md) — the managed system a ticketing system is configured as. * [Simulation mode](/administration-guide/lifecycle/simulation-mode.md) — the general mechanism ticket review builds on. * [Integration patterns for external systems](/administration-guide/operations/enterprise-integrations.md) — when a ticket is the right pattern, and when provisioning or a workflow task is. * [Manage non-human identities](/administration-guide/nhi.md) — the identities the NHI triggers report on. --- # 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.md?ask=&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.