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
- Data model and import order
The tables behind Incident Response Platform
Incident Response Platform ships with 12 tables, grouped here by the feature that uses them. Every record your team works with lives in one of them, and you can add fields and tables in Proto.
- Tables
- 12
- Features
- 7, plus shared settings
- Change it
- Add fields and tables in Proto
How the model is organised
Service context:
Services, Assets, People, Users. Services have an owner; assets belong to a service and people map to users.
Live response:
Incidents, response events, incident updates. Incidents name the service, asset and assigned person; actions and updates point to the incident.
Coverage and recurrence:
On call shifts, Problems. Shifts connect a service to a responder over time; problems connect recurring issues to a service and owner.
Planned work:
Service requests, Changes. Requests identify a requester and service; changes identify a service, risk, window and rollback plan.
Event intake:
Integration receipts. Provider and external event identifiers support receipt reconciliation.
Every table, by feature
- Incidents6
- Response activity4
- On-call coverage5
- Services and assets6
- Problems5
- Requests and changes5
- Integration receipts4
- Shared and settings1
- Incidents
Each record is a service disruption being tracked, used to see what's broken, who owns it, and how fast it's fixed.
Linked to Services, Assets, People - Services
Each record is a service the team supports, used to track its importance, health, and who's responsible for it.
Linked to People - Assets
Each record is a piece of equipment or system component, used to know what's running, where, and its current condition.
Linked to Services - People
Each record is a team member, used to know their role and whether they're available to respond or be assigned work.
Linked to Users - Response events
Each record logs one action a responder took during an incident, so the team can trace exactly what happened and when.
Linked to Incidents, People - Incident updates
Each record is a status note posted during an incident, used to keep everyone informed as the situation develops.
Linked to Incidents, People
- Response events
Each record logs one action a responder took during an incident, so the team can trace exactly what happened and when.
Linked to Incidents, People - Incident updates
Each record is a status note posted during an incident, used to keep everyone informed as the situation develops.
Linked to Incidents, People - Incidents
Each record is a service disruption being tracked, used to see what's broken, who owns it, and how fast it's fixed.
Linked to Services, Assets, People - People
Each record is a team member, used to know their role and whether they're available to respond or be assigned work.
Linked to Users
- On call shifts
Each record is a block of time someone is on call for a service, used to know who to page and when they're covered.
Linked to Services, People - Services
Each record is a service the team supports, used to track its importance, health, and who's responsible for it.
Linked to People - People
Each record is a team member, used to know their role and whether they're available to respond or be assigned work.
Linked to Users - Incidents
Each record is a service disruption being tracked, used to see what's broken, who owns it, and how fast it's fixed.
Linked to Services, Assets, People - Response events
Each record logs one action a responder took during an incident, so the team can trace exactly what happened and when.
Linked to Incidents, People
- Services
Each record is a service the team supports, used to track its importance, health, and who's responsible for it.
Linked to People - Assets
Each record is a piece of equipment or system component, used to know what's running, where, and its current condition.
Linked to Services - Incidents
Each record is a service disruption being tracked, used to see what's broken, who owns it, and how fast it's fixed.
Linked to Services, Assets, People - People
Each record is a team member, used to know their role and whether they're available to respond or be assigned work.
Linked to Users - Changes
Each record is a planned change to a service, used to schedule work safely and know how to undo it if something breaks.
Linked to Services - Problems
Each record tracks a recurring or underlying issue behind incidents, used to find and fix root causes instead of just symptoms.
Linked to Services, People
- Problems
Each record tracks a recurring or underlying issue behind incidents, used to find and fix root causes instead of just symptoms.
Linked to Services, People - Services
Each record is a service the team supports, used to track its importance, health, and who's responsible for it.
Linked to People - People
Each record is a team member, used to know their role and whether they're available to respond or be assigned work.
Linked to Users - Incidents
Each record is a service disruption being tracked, used to see what's broken, who owns it, and how fast it's fixed.
Linked to Services, Assets, People - Changes
Each record is a planned change to a service, used to schedule work safely and know how to undo it if something breaks.
Linked to Services
- Service requests
Each record is something a person asked the IT team to do, used to track requests from ask to completion.
Linked to People, Services - Changes
Each record is a planned change to a service, used to schedule work safely and know how to undo it if something breaks.
Linked to Services - Services
Each record is a service the team supports, used to track its importance, health, and who's responsible for it.
Linked to People - People
Each record is a team member, used to know their role and whether they're available to respond or be assigned work.
Linked to Users - Assets
Each record is a piece of equipment or system component, used to know what's running, where, and its current condition.
Linked to Services
- Integration receipts
Each record confirms one alert or event arrived from an external monitoring tool, so the team can catch missed or duplicate signals.
- Incidents
Each record is a service disruption being tracked, used to see what's broken, who owns it, and how fast it's fixed.
Linked to Services, Assets, People - Services
Each record is a service the team supports, used to track its importance, health, and who's responsible for it.
Linked to People - Assets
Each record is a piece of equipment or system component, used to know what's running, where, and its current condition.
Linked to Services
Keys and references
Retain source identifiers during migration and map them to stable service, asset and person records. Import incident references only after those records exist. Keep the provider’s external event identifier on each receipt and review repeated arrivals before applying them. Dates should use one agreed time zone so shift boundaries and incident intervals remain comparable.
Migration order
- Load Users and People, then agree operating roles and active responders.
- Load Services with their owners, followed by Assets tied to those services.
- Load on call shifts and review start, end, responder and escalation level.
- Load open Incidents, then their response events and incident updates.
- Load Problems, Changes and service requests with their service and person references.
- Load integration receipts and reconcile provider identifiers and handling statuses.
Set up Incident Response Platform your way.
Start free, then use Proto to change fields, steps and approvals before your team goes live.