Let the ITSM own the incident lifecycle: no auto-close, reopen from Resolved, Closed set only by the ITSM

Current behaviour

• Concert Operate moves an incident from Resolved to Closed after a fixed period of about 120 seconds (see IRISCART-I-2196). It decides when an incident is finished without regard to the ITSM ticket.
• Once an incident is Closed, a repeat of the same fault creates a new incident. The integration then either raises a new ticket or needs custom logic to map the new incident back to the existing ticket.
• We have not found a supported way for the ITSM ticket state to drive the Concert Operate incident state, including a reopen.

Our process
Under our ITIL process, ServiceNow is the system of record for the incident lifecycle.

• Resolved can be undone: the customer or the NOC can reopen a Resolved ticket during the ServiceNow reopen window if the fault isn’t fixed or comes back.
• Closed is final, and only ServiceNow sets it, after the reopen window ends.
• Concert Operate needs to mirror that state rather than run its own clock.

Impact today

• Concert Operate and ServiceNow show different states for the same fault.
• Repeat faults create duplicate tickets, which inflates ticket counts, breaks MTTR (mean time to repair) and SLA reporting, and adds triage work.
• Every customer that integrates with an ITSM has to build and maintain its own reopen and mapping logic.

Requested capability

1. A lifecycle ownership setting per incident policy or per integration, with two options: owned by Concert Operate (today’s behaviour) or owned by an external system.
2. When the external system owns the lifecycle, Concert Operate never auto-closes the incident. Closed is set only through the integration or the API.
3. Reopen: an incident can move from Resolved back to In progress through the UI, the API and the ServiceNow integration. It keeps the same incident ID, alerts, timeline and ticket link.
4. New alerts that correlate to a Resolved incident reopen that incident and send a reopen update to the linked ticket, instead of creating a new incident.
5. A configurable two-way state map between ServiceNow incident states (New, In Progress, On Hold, Resolved, Closed, Canceled) and Concert Operate incident states, including resolution code and notes.
6. Available in both the built-in ServiceNow integration and the v2 Issue Resolution API. That way custom integrations, for example IBM Concert Workflows using the TM Forum TMF621 Trouble Ticket API v5.0, can use it too.
7. State updates are idempotent: applying the same update twice has no extra effect. The incident timeline records which system made each change.

Acceptance criteria

• When a ServiceNow ticket is reopened from Resolved, the linked incident goes back to In progress with the same incident ID.
• An incident stays Resolved indefinitely until ServiceNow sends Closed.
• After Closed, a repeat of the fault creates a new incident, linked to the previous one as a related incident.
• Applying the same state update twice causes no further change.