Ticketing system

The product does three things against the ticketing system, and that is all it does there.

When	What happens	Where you see it
An event is created	A request is opened, and its number is stored on the event	The wizard's summary screen, the "Request" row
The event is edited or the window moves	The request is updated, including the new activity time	The event editor
The event is cancelled	The request is cancelled	The event editor

The request number is shown in the event editor. Where the deployment has configured an address for viewing a request, the number becomes a link; where it has not, it is shown as plain text. It is also available as an automatic field in templates, named request number, so it can be placed in the body of an email or an invitation.

What the product offers the ticketing system

What is sent	Source
The update type	The choice in the wizard's first step
Host, IP address, system, site, zone and domain	The inventory row of the primary host
The list of hosts and systems in the event	The host selection step
Start and end time	The date and time step
The system owner, their email, and the contacts	The owner and contacts step
Comments	The comments box in the wizard
A subject and body from the template	The update type's template

The ticketing system on the other side uses what it can map and ignores the rest. That is deliberate: the same request serves a system that stores everything in numbered fields, a system that expects a document, and a system that tracks changes by email.

The template is what triggers the request

An update type with no request template opens no request, and the summary screen says exactly that. The same template serves the email, the calendar invitation and the request — not three templates that have to be remembered together.

When there is no ticketing system

When a request fails

A failure to open a request does not cancel the window. The event is saved, the request row on the summary screen reads "not opened" with the reason, and the invitations still go out. The opposite behavior, where a secondary service failing cancels an action the user already confirmed, is worse.

Updating and cancelling a request behave the same way: neither fails the save and neither fails the cancellation. A moved window is stored even when the request did not receive the update.

Vendor neutrality

The contract with the ticketing system is defined in the product's own terms — open, update, cancel — and not in terms of one particular system. Which system sits behind it is a configuration question, and the screens that have to name it read the name from the configuration. An error message shown to a user describes what happened and what can be done about it.

The rest of the integrations are described in Supported integrations, and the systems the product knows by category in The system catalog.