> 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/tickets.md). # Track tickets The Tickets screen of a ticketing managed system — every ticket OpenIAM raised, its delivery state and status, retry and discard of failed deliveries, the ticket details and audit trail, and the Ticke ## What this is, and when you need it Every ticket OpenIAM raises in Jira or ServiceNow gets a record in OpenIAM: which rule created it, which subject it is about, whether OpenIAM's last change reached the ticketing system, and the status the ticketing system reports back. The **Tickets** screen of the ticketing managed system lists those records, lets you send a failed delivery again or give up on it, and opens the details and audit trail of one ticket. Requesters and approvers see the same tickets in SelfService, next to their request. Come here when a service desk says a ticket never arrived, when you want to see what a new rule produced, or when you need evidence of what OpenIAM sent and when. To change *what* a ticket says, edit the rule instead ([Write a ticket rule](/administration-guide/ticketing/ticket-rules.md)); to check rules before anything is sent, use [Review tickets before they are sent](/administration-guide/ticketing/review-before-sending.md). The screen shows only tickets OpenIAM created. A ticket someone opened by hand in Jira or ServiceNow is not listed and is never matched by a rule (see [One ticket per subject](/administration-guide/ticketing/overview.md#concept-one-ticket-per-subject)). ## At a glance | | | | --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | **Where** | **Provisioning → Managed System**, open the ticketing system, then **Tickets** in its menu (`/webconsole/tickets?id=`) | | **What you can do** | Filter and search the tickets, open a ticket in the ticketing system, retry or discard a failed delivery, read a ticket's audit trail | | **What you cannot do here** | Create, edit, close or resend a delivered ticket; the ticket key is the link to the ticket in Jira or ServiceNow, where it is changed | | **Who sees it** | Administrators who can open the managed system; the menu item appears only on a managed system whose connector is the Ticket Connector | | **SelfService** | A **Ticket** column on the task and request lists, and a ticket line in a task's details | ## The Tickets screen The screen lists the tickets of one ticketing managed system, newest first, 20 per page (10, 20, 50 or 100 rows per page). If you open `/webconsole/tickets` without a managed system, it shows `No ticketing managed system is selected.` | State | What you see | | -------------------------- | ----------------------------------------------------------- | | No ticket yet | `No tickets have been raised in this ticketing system yet.` | | Filters exclude everything | `No tickets match the filters.` | | The list cannot be read | `The tickets could not be loaded.` | For the running example, the **Service Desk Jira** list holds **ACCESS-142**, opened when Jordan Lee requested *Finance Reports* access for Sam Patel, and, on a bad day, a **Provisioning failure** ticket that has not been created yet because Jira was unreachable. ### Filters Every select starts at **Any**. Changing a filter returns you to the first page. **Clear filters** resets them all and is disabled when none is set. #### Delivery Shows the tickets whose last delivery is **Pending**, **Delivered** or **Failed**. These three states summarize OpenIAM's own record of the send, not the ticket's status in the ticketing system; the nine underlying states are explained in [Delivery states](/administration-guide/ticketing/overview.md#delivery-pending). #### Trigger group Shows the tickets of one trigger group: **Request**, **Access revoked**, **User created**, **User edited**, **User terminated**, **Provisioning**, **Fulfilment** or **Non-human identity**. The trigger group, together with the subject, is what an update or close rule uses to find a ticket, so this filter shows exactly the tickets a rule of that group can reach. **Fulfilment** is reserved and never has tickets in this release. #### Rule Shows the tickets a given rule of this system created. A ticket whose rule was deleted keeps its record but no longer belongs to any rule, so it does not appear under any rule here. #### Created from and Created to Two date fields. **Created from** keeps tickets created on or after that day; **Created to** keeps tickets created up to the end of that day. Both are inclusive. #### Search Finds a ticket by its key in the ticketing system or by its subject key. Type the text and press **Enter**, or leave the field; the search is not applied while you type. Text shaped like an issue key — letters, a hyphen and digits, such as `ACCESS-142` — is matched against the ticket key; anything else is matched against the subject key. The subject key is the internal identifier of the subject (a request, a user, a user and a managed system, or a non-human identity), so searching by key is usually the quicker route. ServiceNow numbers such as `SCTASK0010042` have no hyphen and are searched as subject keys; filter by **Rule** or **Trigger group** to find a ServiceNow ticket. ### Failed deliveries **Failed deliveries** is a preset button. It clears the other filters and shows only the tickets whose last delivery failed; the button is filled while it is active. Start here when someone reports a missing ticket. ### Columns #### Key The ticket's key in the ticketing system — `ACCESS-142` in Jira, `SCTASK0010042` in ServiceNow — linked to the ticket, opening in a new tab. Clicking the key does not open the ticket details; click elsewhere in the row for those. **Not created yet** means the ticketing system has not yet confirmed the create, so OpenIAM has no key: the create is pending, failed, or waiting in [simulation](/administration-guide/ticketing/review-before-sending.md). #### Subject The request, user or non-human identity the ticket is about, by name. For ACCESS-142 it is the *Finance Reports* request; for a **Provisioning failure** ticket it is the user whose account failed. When the subject cannot be resolved any more (the user was deleted, say), the column shows a placeholder instead of a name. #### Trigger The trigger of the **last** event that changed the ticket, not the one that created it. ACCESS-142 shows **Request submitted** after it is opened, **Request step decided** after Priya Nair approves, and **Request completed** once rule 3 closes it. #### Rule The rule that created the ticket. **No rule** means the rule has since been deleted; deleting a rule keeps its tickets. #### Delivery A chip: **Pending** (amber), **Delivered** (green) or **Failed** (red). Hover over a **Failed** chip to read the last error. The column answers "did OpenIAM's last change reach the ticketing system?", which is a different question from the next column. #### Ticket status The ticket's own status and resolution in the ticketing system, as `status / resolution` — for example `Done / Done` in Jira or `Closed Complete` in ServiceNow. OpenIAM learns it in two ways: from the reply to a close transition, and from the [ticket synchronization](/administration-guide/ticketing/policy-map-and-sync.md#sync-ticket-sync), which reads the status, resolution and assignee of OpenIAM's tickets back every 15 minutes. A status changed by a person in Jira therefore appears here at the next synchronization, not at once. #### Last synced When OpenIAM last heard from the ticketing system about this ticket: a successful reply to a delivery, or the last synchronization that read it. A ticket whose **Last synced** keeps moving while its status does not is simply unchanged in the ticketing system. The **Created** column is when OpenIAM created its record, which for a pending create is before the ticket exists in the ticketing system. ## Fix a failed delivery A delivery fails when the connector or the ticketing system rejects it: wrong credentials, a project the account cannot create in, a transition the issue does not offer, an outage. OpenIAM retries a failed delivery on its own with a growing delay until it has failed five times (the default), and records each attempt (see [Delivery and retries](/administration-guide/ticketing/operate-ticketing.md#operate-delivery-and-retries)). The two actions below let you act before or after those retries. Only failed rows carry the actions and a selection checkbox. The header checkbox selects every failed ticket on the page. With failed rows selected, a bar above the table shows `{n} selected`, **Retry selected** and **Discard selected**. One action takes at most 100 tickets. ### Retry **Retry** (on the row or in the ticket details) and **Retry selected** send the failed delivery again now, without waiting for the next automatic attempt. It works after the automatic retries are exhausted too. What a retry sends depends on what failed: | Failed operation | What Retry does | | ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Create | First searches the ticketing system for a ticket carrying this subject's label (`openiam-`). If one exists — the create reached the ticketing system but the reply was lost — OpenIAM adopts it: the record becomes **Delivered** with that key and nothing is sent. Otherwise the stored create is sent again | | Update or close | Sends the stored request again. Updates or closes that were waiting for the ticket to exist are sent after it, oldest first | The row turns **Pending** while the retry is under way and changes again when the reply arrives. A toast reports the outcome, `Retry: {sent} sent, {failed} failed.`, with the first error when one of them failed. A retry fixes nothing by itself: if the cause is still there, the delivery fails again with the same **Last error**. Fix the cause first — the credential on the managed system, the rule's project or transition — then retry. ### Discard **Discard** and **Discard selected** stop OpenIAM from retrying a failed delivery. They open **Discard failed deliveries**, which asks: `Discard {n} failed delivery(ies)? A failed create is removed; a failed update or close is marked as delivered and no longer retried.` | Failed operation | What Discard does | | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Create | Deletes OpenIAM's record. Nothing existed in the ticketing system, so nothing is removed there. The subject has no ticket any more: the next matching event of a create rule opens a new one | | Update or close | Marks the record **Delivered** and clears the retry state; the last error is kept. The change that failed is never sent. A discarded close leaves the ticket open in the ticketing system, and the record no longer counts as closed | Discard is the right choice when the change no longer matters — a comment on a request that has since been completed — or when you made the change by hand in the ticketing system. The toast reports `Discard: {discarded} discarded, {failed} failed.` If the ticket you discard is open in the details panel, the panel closes. ## Ticket details ### The ticket details panel Click a row to open the details on the right. The panel title is the ticket key, or **Ticket** while there is none. A failed delivery shows **Retry** and **Discard** at the top. An empty value shows `—`. | Field | What it holds | | ------------------------ | ------------------------------------------------------------------------------------------------------ | | **Key** | The ticket key, linked to the ticket in the ticketing system | | **Subject** | The request, user or identity the ticket is about | | **Summary** | The ticket's summary as OpenIAM last sent it, or as it read it back when it adopted an existing ticket | | **Trigger group** | The ticket's trigger group; with the subject it decides which events reach this ticket | | **Last trigger** | The trigger of the last event that changed the ticket | | **Rule** | The rule that created it | | **Delivery** | The delivery chip | | **Ticket status** | The status in the ticketing system | | **Resolution** | The resolution in the ticketing system, for example a Jira resolution or a ServiceNow close code | | **Assignee** | The assignee in the ticketing system, read back by the synchronization | | **Last error** | Why the last delivery failed | | **Retry count** | How often OpenIAM has retried the failed delivery | | **Next attempt** | When OpenIAM retries it next | | **Last synced** | When OpenIAM last heard from the ticketing system about this ticket | | **Sync status** | `OK` after a successful reply or synchronization | | **Created**, **Updated** | When OpenIAM created and last changed its record | There is no action to close, edit or resend a delivered ticket. To act on the ticket itself, open it in Jira or ServiceNow through the **Key** link; to make OpenIAM send something, let a rule do it. ### Last error The reason the last delivery failed, in red, as the connector or the ticketing system reported it. The connector puts the HTTP status and the ticketing system's own error messages into it, for example: * `Jira rejected the credentials (HTTP 401): …` — the account e-mail or API token on the managed system is wrong or revoked. * `Jira denied access (HTTP 403)` — the account may not do this in the project. * `Transition 'Done' is not available for issue ACCESS-142; available: …` — the rule's transition does not exist in the issue's current status. * `Deferred UPDATE expired after 900000 ms` — an update waited for a create that never succeeded. The full list, with causes and fixes, is in [Operate ticket integration](/administration-guide/ticketing/operate-ticketing.md#operate-troubleshooting). A failure the connector reports without any text shows `The connector reported a failure without an error text`. ### Retry count and next attempt **Retry count** is how many times the delivery has failed. **Next attempt** is when the retry job sends it again: with the defaults, 10 minutes after the first failure, then 20, 40 and 80 minutes after the following ones. When **Retry count** reaches the maximum (five by default), **Next attempt** is empty: OpenIAM has stopped retrying and records the delivery as failed for good. The record stays on the list under **Failed deliveries** until you retry or discard it. A successful delivery resets both fields. ### Audit trail Below the fields, **Audit trail** lists every audit record of the ticket, newest first: the action and its result, the time, the description and, for a failure, the reason in red. | Action | When it is written | | ------------------------------------------------ | --------------------------------------------------------------------------------------------------------- | | `TICKET_CREATE`, `TICKET_UPDATE`, `TICKET_CLOSE` | When OpenIAM sends the operation, and again when the reply arrives | | `TICKET_DELIVERY_FAILED` | When a reply reports a failure, when the retries are exhausted, or when a waiting update or close expires | | `TICKET_RETRY` | For every automatic or manual retry | | `TICKET_SYNC` | When a retry adopted an existing ticket instead of creating one | The send record carries the payload OpenIAM sent — the rendered summary, description, comment and fields — and the reply record carries the response, so the trail shows exactly what reached the ticketing system. Both are cut to 4000 characters by default and flagged as truncated when cut; connection settings and any attribute whose name contains `password`, `secret`, `token`, `credential` or `apikey` are never recorded. Each record names who started the event — the administrator who saved the user, the approver, the requester — or the system user for scheduled runs. The same records are in the audit log, as children of the event that caused them; see [Audit actions](/administration-guide/ticketing/operate-ticketing.md#operate-audit-actions). ## In SelfService ### The Ticket column When at least one active ticketing managed system exists, SelfService adds a **Ticket** column after the request ID column on the **My tasks**, **Request administration** and **Request history** lists. For each request it shows the tickets OpenIAM raised for it: * a ticket with a key appears as the key, linked to the ticket, opening in a new tab (`Open ticket ACCESS-142 in a new tab`); * a ticket without a key yet appears as a badge, **Pending**, **Delivered** or **Failed**; * a request without tickets shows `—`. A task's details show the same ticket line among the facts of the decision, and alone for a closed request. Nothing is configured in SelfService; with no active ticketing system the column is not shown. A **Failed** badge is a sign for an administrator to look at the Tickets screen; the requester cannot act on it. ## The life of ACCESS-142 {% stepper %} {% step %} **Jordan Lee submits the request.** Rule 1, **Access request opened**, matches **Request submitted**. OpenIAM writes a record for the *Finance Reports* request — **Delivery** **Pending**, **Key** **Not created yet** — and sends the create to Service Desk Jira. {% endstep %} {% step %} **Jira creates the issue.** The reply carries the key: the record shows **ACCESS-142**, **Delivered**, and the audit trail has a `TICKET_CREATE` send and its reply. In SelfService, Jordan Lee's request now shows **ACCESS-142** in the **Ticket** column. {% endstep %} {% step %} **Priya Nair approves the step.** Rule 2, **Access request decided**, finds the same record — same trigger group, same request — and sends a comment. **Trigger** changes to **Request step decided**. {% endstep %} {% step %} **The request completes.** Rule 3, **Access request finished**, sends the **Done** transition with the closing comment `Request completed.` The reply reports the new status, so **Ticket status** shows `Done` and **Trigger** shows **Request completed**. {% endstep %} {% step %} **Someone reassigns the issue in Jira.** Within 15 minutes the ticket synchronization reads it back, and **Assignee** in the details shows the new person; **Last synced** moves. {% endstep %} {% endstepper %} ## Verification * The list shows a new row within seconds of the event that should have raised it, with **Pending** turning **Delivered** and a key appearing. * The key opens the right ticket in Jira or ServiceNow, and its summary matches **Summary** in the details. * **Failed deliveries** is empty, or every row in it has a **Last error** you understand. * The audit trail of a delivered ticket ends with a successful reply record for each send. ## When it goes wrong | Symptom | Likely cause | Resolution | | ------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | No row appears at all | No rule matched the event, the rule is disabled, or the managed system is inactive | Check the rule's trigger and **Applies to** card in [Write a ticket rule](/administration-guide/ticketing/ticket-rules.md), and [Operate ticket integration](/administration-guide/ticketing/operate-ticketing.md#operate-troubleshooting) | | The row stays **Pending** with **Not created yet** | The Ticket Connector is not running or not consuming its queue, or the system is in simulation mode | Check the connector ([Connect a ticketing system](/administration-guide/ticketing/connect-a-ticketing-system.md)); look for the request on the Simulation screen ([Review tickets before they are sent](/administration-guide/ticketing/review-before-sending.md)) | | **Failed** with `HTTP 401` in **Last error** | The credential on the managed system is wrong, expired or revoked | Fix it on the managed system, run **Test connection**, then **Retry** | | **Failed** with `Transition '…' is not available` | The close rule's transition does not exist in the issue's current status | Correct the rule's **Transition**, then **Retry**, or **Discard** and close the issue by hand | | **Retry** reports `The delivery of this ticket has not failed.` | The ticket was delivered or is pending again since the page loaded | Reload the list | | **Retry** reports `No stored request to retry for ticket …` | The request OpenIAM stored for the delivery is gone | **Discard** it; the next event of a create rule opens a new ticket | | A ticket closed in Jira shows **Delivered** with an old **Ticket status** | The synchronization has not run since, or its batch task is disabled | Wait for the next run, or check the batch task ([The TICKET policy map and ticket synchronization](/administration-guide/ticketing/policy-map-and-sync.md#sync-ticket-sync)) | | A SelfService user sees **Failed** next to a request | The ticket's create failed | Retry it from **Failed deliveries** after fixing the cause | ## Related * [How ticket integration works](/administration-guide/ticketing/overview.md) — subjects, trigger groups and delivery states. * [Write a ticket rule](/administration-guide/ticketing/ticket-rules.md) — change what the tickets say and when they are raised. * [The TICKET policy map and ticket synchronization](/administration-guide/ticketing/policy-map-and-sync.md) — where **Ticket status**, **Resolution** and **Assignee** come from. * [Operate ticket integration](/administration-guide/ticketing/operate-ticketing.md) — retries, properties, audit actions and the full troubleshooting table. * [Audit actions and retention](/administration-guide/reference/audit-actions-and-retention.md) — how long the audit trail is kept. --- # 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/tickets.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.