> 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/review-before-sending.md). # Review tickets before they are sent Hold the tickets a ticketing managed system would create, update or close in simulation mode, read and edit each captured request, rebuild it after changing a rule, and apply it when it is right. ## What this is, and when you need it A new ticket rule fires on real events, and a mistake in it lands in front of the service desk: a ticket for every user edit, a summary with an empty name, a close on the wrong transition. A ticketing managed system can run in **simulation mode** instead. Every ticket operation you choose to simulate is captured on the system's **Simulation** screen rather than sent: you see what OpenIAM *would* have sent to Jira or ServiceNow, change it if you need to, and apply it — or delete it — when you are satisfied. Use it while you bring a ticketing system or a new rule into service, and whenever you change a rule's templates or conditions on a system people already rely on. It is the same simulation mode that user and group provisioning use; this page covers what is specific to tickets. The general mechanism, the screen's common controls and its audit records are in [Simulation mode](/administration-guide/lifecycle/simulation-mode.md). Simulation is not a test environment. The events are real, the rules are the live rules, and an applied request creates a real ticket. ## At a glance | | | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | **Turn on** | On the ticketing managed system, select operations in **Simulation Requests**: **Create ticket**, **Update ticket**, **Close ticket** | | **Review** | The managed system's menu → **Simulation** (`/webconsole/simulation`), entity type **Ticket** | | **Per captured request** | View it, **Edit payload**, **Rebuild** from the current rule, apply it, or delete it | | **What it protects against** | A wrong template, filter, project or transition reaching the ticketing system | | **What it does not do** | Change which rules match; rule matching, subjects and OpenIAM's ticket records work as they do without simulation | | **Reversible** | Yes — remove the operations from **Simulation Requests** to send again; captured requests stay until you apply or delete them | ## Turn simulation on for a ticketing system {% stepper %} {% step %} **Open the managed system.** In **Provisioning → Managed System**, open the ticketing system, for example **Service Desk Jira**. {% endstep %} {% step %} **Select the operations to capture.** In **Simulation Requests**, a ticketing system offers three operations instead of the user and group operations: **Create ticket**, **Update ticket** and **Close ticket**. Select the ones you want to review. To try a new create rule, **Create ticket** is enough; to try the whole lifecycle of the running example, select all three. {% endstep %} {% step %} **Save the managed system.** From now on every operation of that kind is captured instead of sent. {% endstep %} {% endstepper %} {% hint style="info" %} While **Create ticket** is simulated, an update or close for a subject that has no ticket yet is captured too, even if **Update ticket** or **Close ticket** is not selected: the ticket it would act on exists only as a captured create, so there is nothing to send it to. {% endhint %} Rules still match exactly as they do without simulation, and OpenIAM still writes its ticket record. On the **Tickets** screen a captured create appears as a **Pending** row with **Not created yet**; it stays that way until the captured request is applied. Unlike a normal pending delivery, a captured request is never resent by the retry job. ## Captured ticket requests ### Ticket rows on the Simulation screen Open **Simulation** from the managed system's menu and set the entity type filter to **Ticket**. Each row is one ticket operation OpenIAM would have sent. | Column | For a ticket row | | --------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | **Entity Name** | The subject the ticket is about — the request, the user, the non-human identity — or `Unknown subject` when it can no longer be resolved | | **Entity Type** | `TICKET` | | **Operation** | **Create ticket**, **Update ticket** or **Close ticket** | | **Trigger** | The trigger of the event that produced the request, such as **Request submitted** | | **Rule** | The rule that produced it, such as **Access request opened** | | **Date** | When the request was captured | The **Trigger** and **Rule** columns appear as soon as the list holds at least one ticket row. A ticket row has three row actions besides selection: the view icon, **Edit payload** and **Rebuild**. When Jordan Lee submits the *Finance Reports* request with all three operations simulated, the list gets a **Create ticket** row from **Access request opened**; Priya Nair's approval adds an **Update ticket** row from **Access request decided**; completion adds a **Close ticket** row from **Access request finished**. All three belong to the same ticket. ### View a captured request The view icon opens **Ticket request: {subject}**. It lists the fields OpenIAM would send, in the order of the [TICKET policy map](/administration-guide/ticketing/policy-map-and-sync.md#map-ticket-policy-map): project, issue type, summary, description, priority, labels, transition and comment, then any extra fields. Description and comment keep their line breaks, so you see the paragraphs and `-` bullet lines as they will be written. A request without attributes shows `The request has no attributes.` What you read here is the rendered result: placeholders are already replaced by the event's values. An empty field where you expected a name usually means the trigger cannot fill that placeholder — see [Template placeholders](/administration-guide/ticketing/ticket-rules/placeholders.md). **Apply** in the dialog applies this one request; **Cancel** closes it. ### Edit the payload **Edit payload** opens **Edit payload: {subject}**, a form with one field per attribute. It always shows the eight standard fields, even those the request does not carry, followed by any other attribute in the request. | Rule | Behaviour | | --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Sensitive attributes | Shown disabled with `This value is hidden and cannot be edited.` | | Multi-valued attributes, such as labels | One field; `Separate values with commas.` | | A create | Project, issue type and summary are required (`Required for a ticket that is created.`); on a ServiceNow system the issue type — the category — is optional | | What is saved | Only the fields you change; **Save** stays disabled until something changed (`No changes yet.`) and while a required field is empty (`Enter a value for {field}.`) | On save the toast reads `The ticket payload was saved.` The change applies to this captured request only; the rule is unchanged, so the next event produces the rule's version again. If a rule is wrong, fix the rule and [rebuild](#sim-rebuild) instead of editing every row. The request is checked again when you apply it. These are the messages you can meet on save or on apply: | Message | Meaning | | ------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | | `Enter at least one attribute value.`, or on apply `the payload has no attributes` | The payload would be empty | | `Unknown attribute: {name}`, or on apply `unknown attribute {name}` | The attribute is neither a row of the TICKET policy map nor a valid field id of the ticketing system | | `The attribute {name} cannot be edited.` | It is a sensitive attribute | | `{name} is required for a ticket that is created.`, or on apply `project is required`, `issuetype is required`, `summary is required` | A create without project, issue type (Jira only) or summary | | `the payload belongs to managed system …, not …` | The request was captured for another managed system | | `The stored ticket request cannot be read.` | The stored request is damaged; delete the row and let the event happen again | ### Rebuild a captured request **Rebuild** opens **Rebuild request: {subject}**: `The request is built again from the captured event with the current ticket rules and TICKET policy map. Changes made with Edit payload are replaced.` OpenIAM keeps the event that produced each captured request. Rebuild runs that event through the rule again — its current conditions, templates, project, priority and fields — and replaces the payload. This is the quick way to check a rule fix: correct the summary template, rebuild the captured row, view it. Rebuild re-checks the match. If the changed rule no longer applies to the event — you narrowed **Applies to**, or disabled the rule — the rebuild fails with `the rule no longer matches the event` and the row is left as it was; delete it if it should not be sent. On success the toast reads `The request was rebuilt with the current rules and policy map.` ## Apply or delete Applying sends the captured request to the ticketing system through the Ticket Connector, exactly as if simulation had been off at the time; deleting removes it without sending. Both use the common controls of the Simulation screen (**Apply Selected**, **Apply in Sequence**, **Delete Selected**, **Delete All**), described in [Simulation mode](/administration-guide/lifecycle/simulation-mode.md#the-screen-and-its-controls). ### Apply the requests of one ticket in order Apply a ticket's requests oldest first: an update or close sent before its create has no ticket to act on. **Apply in Sequence**, from **Review and apply in sequence**, does that for you. For a ticket row it picks every pending request **of the same ticket** captured at or before the one you selected, applies them oldest first, and stops at the first failure: the failing request and every later one stay in the list. For the running example, select the **Close ticket** row and apply in sequence: the create, the comment and the close go to Jira in that order, and ACCESS-142 is created and closed. When some requests of an ordinary apply fail, the screen shows `{failed} of {total} simulation requests were not applied and are kept in the list. The reason is recorded in the audit log.` The reason is in the `DISPATCH_SIMULATION_REQ` audit record of each request. ### What happens after you apply The applied request is removed from the list, and OpenIAM's ticket record follows the reply as for any delivery: the **Tickets** row gets its key and turns **Delivered**, or turns **Failed** with the reason in **Last error**. A failed delivery is then retried automatically like any other. One case is not covered: if the connector never answers an applied request — it was down when you applied, say — the ticket record stays **Pending**, and the retry job does not pick it up, because a captured request carries no next attempt. Check the **Tickets** screen after applying, and apply again from the audit evidence if a row stays pending. ### Delete a captured request Deleting a captured request sends nothing. OpenIAM's ticket record for it stays as it was — a captured create leaves a **Pending** row with **Not created yet** on the **Tickets** screen, which neither retry nor discard can act on because the delivery has not failed. Prefer correcting the rule and rebuilding over deleting when the subject should still get a ticket. ## Take the system out of simulation Resolve the captured ticket rows first — apply or delete them — then remove **Create ticket**, **Update ticket** and **Close ticket** from **Simulation Requests** and save. Turning simulation off does not send what was captured; the next event for the same subject is sent while the old rows are still waiting, which for tickets means an update can reach a ticket whose earlier comment never did. ## Verification * With **Create ticket** simulated, a matching event adds a **Create ticket** row with the expected **Trigger** and **Rule**, and nothing appears in Jira or ServiceNow. * The view of that row shows the summary and description with every placeholder filled. * After **Rebuild**, the view shows the rule's current content. * After applying, the **Tickets** screen shows the ticket with a key and **Delivered**, and the key opens it in the ticketing system. ## When it goes wrong | Symptom | Likely cause | Resolution | | ------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | A matching event produces no captured row and no ticket | No rule matched, or the operation was not selected in **Simulation Requests** (an update for an existing ticket is sent unless **Update ticket** is selected) | Check the rule ([Write a ticket rule](/administration-guide/ticketing/ticket-rules.md)) and the selected operations | | **Simulation Requests** offers user operations, not the ticket ones | The managed system's connector is not the Ticket Connector | Fix the connector on the managed system ([Connect a ticketing system](/administration-guide/ticketing/connect-a-ticketing-system.md)) | | Rebuild fails with `the rule no longer matches the event` | The rule was changed so that it no longer applies to that event, or it is disabled | Delete the row if that is intended; otherwise correct the rule and rebuild again | | An applied update or close fails, the create was not applied | The requests were applied out of order | Apply the create first, or use **Apply in Sequence** from the latest row | | A placeholder renders empty in the view | The trigger cannot fill it, or the subject has no such value | Check the placeholder's triggers in [Template placeholders](/administration-guide/ticketing/ticket-rules/placeholders.md); edit the payload for this one request | | The ticket record stays **Pending** after apply | The connector did not answer the applied request | Check the connector, then look at the `DISPATCH_SIMULATION_REQ` audit record of the apply | ## Related * [Simulation mode](/administration-guide/lifecycle/simulation-mode.md) — the common mechanism, the screen's controls, and its audit records. * [Write a ticket rule](/administration-guide/ticketing/ticket-rules.md) — the rule a rebuild re-renders. * [Template placeholders](/administration-guide/ticketing/ticket-rules/placeholders.md) — why a value renders empty. * [Track tickets](/administration-guide/ticketing/tickets.md) — the ticket record of an applied request. * [The TICKET policy map and ticket synchronization](/administration-guide/ticketing/policy-map-and-sync.md) — the fields a captured request carries. --- # 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/review-before-sending.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.