Problems and receipts

An incident is the immediate response to a disruption. A problem record holds the longer investigation: a title, statement, root cause, opening date, service, owner and state. The Service Manager can give a named person responsibility for the investigation and follow it from open through investigation, known error and resolution. The record should state what is known, rather than merely repeat an incident summary. It does not replace the incident’s own asset, priority, assignee or dated response updates.

An integration receipt records the provider, external event identity, received date, payload hash and processing state. Operations can use it to inspect whether an incoming event was received, applied, rejected or failed. The external event identity is the key for reconciliation with the sender. A receipt should help the team find a rejected delivery without claiming that the related incident or request was changed until that result has been checked.

The Service Manager owns follow-up; the Incident Coordinator supplies response context; the Admin oversees event configuration.

• Named investigation. A problem belongs to a service and owner.
• Root-cause account. The statement and findings develop as the work proceeds.
• Event outcome. A receipt retains a stable external identity and processing state.

Agree when repeated incidents become a problem investigation and who can mark the root cause resolved. Decide how the team will link the narrative of the problem to the affected service, since the record does not carry a direct incident reference. For each connected source, agree which provider name and external identity will be recorded and who investigates rejected or failed receipts. Confirm that staff can identify a retransmitted event before applying it again.

Several incidents affect the same service. The Service Manager creates a problem record, gives it an owner and records the suspected cause. The owner updates the statement while investigating, then records the root cause before marking the issue resolved. The original incident responses remain readable with their own times and assigned people.

Separately, an external event arrives twice under the same provider identity. The Admin compares its receipts and processing states before asking for a replay. If one delivery is rejected, the team uses the source identity to investigate the sender and correct the mapping. A received state alone is not treated as proof that downstream work was applied.

• Open problems — Investigations by service, owner and current state.
• Integration receipts — Incoming events requiring reconciliation by provider and result.

Review change and problem work and plan connections.