Service Records

A service record has a name, criticality, status and owner. Incidents, changes, problems, requests and assets refer to that service. A responder can therefore see which business service a technical observation may affect without retyping the service name into each record. Active, Maintenance and Retired states help the owner distinguish current services from records kept for history.

Assets carry an asset tag, optional serial number and location, state and service reference. During an incident, the responder can identify the affected asset and see its service context. The asset register also helps the owner review assigned and maintenance items without turning a saved screen into a separate data source.

• Own. Service Owner maintains the named service, criticality and accountable person.
• Locate. The team links assets to the service and records location and lifecycle state.
• Reconcile. Admin reviews external event receipts where a configured connection supplies data.

An integration receipt records the provider, external event identifier, received time, payload hash and receipt status. It supports traceability when a connector is used. The receipt’s Applied state concerns intake of that external event; it does not by itself say an incident is resolved or a change verified.

Agree on which services are in scope for the first operating cycle and who owns each. Import assets with stable tags and confirm their service links. Map People to Users before relying on owner and assigned-person views. Decide who may update the service and asset registers as the organization changes.

For each external source, agree on provider naming, event identity and how rejected or failed receipts will be reviewed. Configure the connection, credentials and field mapping with the customer. Reconcile a sample event against its source and intended operational record before using the receipt view as a control.

A production service is marked Active and owned by a named person. An assigned asset supports it. An incoming monitoring event is captured with an external event identifier and a Received receipt. The operator checks the event and records an observation for the correct cluster. The responder opens an incident for the affected service and asset if investigation confirms service impact.

If the event is rejected or fails processing, Admin reviews the receipt exception and original provider record. The service owner can still inspect the service and asset register, while the responder’s incident remains an independent work record. This keeps intake status, operational evidence and service resolution understandable to different team members.

• Service asset register — Find assigned or maintenance assets by service and location.
• Event receipt exceptions — Review rejected or failed external events by provider and identifier.

Use observation to incident and integration guidance to plan the source handoff.