Integration receipts

An Integration Receipt records an alert or event that arrived from an external monitoring tool. It holds the provider, external event identifier, received time, payload hash and handling status. The record gives the team a way to check whether a signal arrived, was applied, was rejected or failed. It is useful when a provider reports an event that the response team cannot find in its working queue.

Finance Officer manages receipt records and Service Manager reviews them for operational follow-up. Agree how an exception reaches the Service Manager before connecting a provider or scheduling event intake.

• Capture identity. Keep the provider and external event identifier with the arrival time and hash for later investigation.
• Review status. Distinguish received and applied events from rejected or failed ones instead of treating every arrival as successful handling.
• Reconcile exceptions. Compare an exception with the source event and decide whether it needs correction, a retry or an incident.

Map each provider’s event identifier to the receipt and agree how duplicate deliveries are recognized. Establish who is allowed to change handling status and what each status means for the connection. A payload hash helps compare arrivals, but the external event identifier is the principal way to discuss a particular signal with the provider. Keep a clear procedure for events that are rejected because required information is invalid.

The receipt is an arrival and handling record. The team should separately decide how a monitoring event becomes an incident and which paging system contacts the responder. When tracing a provider signal, check its arrival, handling outcome and any response work in that order. Those are distinct checks.

A monitoring provider reports a service alert during the night. The morning manager looks for the event’s external identifier. The receipt shows its provider, arrival time and a failed handling status. The manager checks the provider event and assigns someone to investigate the failure before assuming a responder missed a page. If the signal represents an actual disruption, the manager opens an incident with the affected service and asset.

For a second delivery of the same provider event, the team compares the identifiers and hash before deciding how it should be handled. A retry should not hide the original failed receipt or create several independent incident narratives. The receipt history gives the connector owner a concrete case for testing.

• Integration receipt exceptions — Rejected and failed event arrivals for operational review.
• Active incidents — Current disruption records to compare with a received monitoring signal.

Review event intake and follow incident response.