These cookies are required for the website to function properly. They ensure security, enable basic features like page navigation, and store user session data. You cannot disable these cookies.
- Incident Response Platform
- Features
- Services and assets
Services and assets
Give incidents a service owner and affected asset context.
OverviewActive services×
Incident Response Platform · Services and assets
New
Active services
Services
| Service name | Criticality | Status | Owner | |
|---|---|---|---|---|
| Service 858 | Low | Active | ||
| Service 649 | Medium | Active | ||
| Service 905 | High | Active | ||
| Service 211 | Low | Active | ||
| Service 797 | Medium | Active |
6 of 6 records
Service 858Services · SRV-94561
LowStatusActive
What you can do
Establish what the team supports
A service record identifies the service name, its criticality, status and owner. An asset record identifies a piece of equipment or a system component, its tag, location and condition, and the service it supports. Linking both to an incident gives responders a starting point for understanding what is affected. It also makes it possible to review disruptions by service rather than by an informal label in a summary.
The Service Manager maintains these records. A responder can view them while investigating. The service owner is the person responsible for that service; the incident’s assigned person is the one working a particular disruption. Those responsibilities may belong to different people and should remain visible.
How the work is organized
- Maintain services. Record each supported service with its owner, criticality and current status.
- Link assets. Give each asset a stable tag and the service it belongs to, then keep its location and condition current.
- Use context in incidents. Select the affected service and asset when opening a disruption so later response work stays connected.
What to agree during setup
Agree how service names map to what users and monitors call them. Decide who may mark a service in maintenance or retired, and how a retired asset is handled when past incidents still refer to it. Establish the asset tagging rule before importing inventory. Reconcile existing service ownership with the People records used for incident assignment and on-call coverage.
Asset condition is operational context. A maintenance label should not substitute for an incident investigation, and a service’s active label should not be taken as a live health probe. Monitoring and inventory systems can remain separate sources connected through an agreed mapping. Review those mappings when a service is renamed or equipment is replaced.
Check the handoff on an actual case
A responder receives an alert about a server component. The Service Manager opens an incident under the relevant service and selects the asset. The asset record shows it is in maintenance and where it is located. The service record shows the owner and criticality. Those details help the manager choose priority and the responder decide who else needs to join the investigation.
After recovery, the team can review other incidents linked to the same service and any open Problem record. If a replacement is planned, the manager can prepare a Change with its own window and rollback plan. The asset status, incident outcome and change decision remain separate records with different owners and times.
What your team sees
- Active services — Supported services with their criticality and named owner.
- Active incidents — Current disruptions tied back to the relevant service and asset.
Follow the work through
What it keeps track of
Data model- Services
- Each record is a service the team supports, used to track its importance, health, and who's responsible for it.
- Assets
- Each record is a piece of equipment or system component, used to know what's running, where, and its current condition.
- Incidents
- Each record is a service disruption being tracked, used to see what's broken, who owns it, and how fast it's fixed.
- People
- Each record is a team member, used to know their role and whether they're available to respond or be assigned work.
- Changes
- Each record is a planned change to a service, used to schedule work safely and know how to undo it if something breaks.
- Problems
- Each record tracks a recurring or underlying issue behind incidents, used to find and fix root causes instead of just symptoms.
Who uses it
Permissions- Service Manager
- , Service Technician
Set up Incident Response Platform your way.
Start free, then use Proto to change fields, steps and approvals before your team goes live.