A restore arrives
The condition clears while the operator is part way down the procedure. The step they were about to take no longer applies, so it goes, and the record says why.
Event types, data handling and routing you set yourself
An event type carries the whole pattern. What the signal means, how its data is read, which severity it takes, who it reaches, and what the operator is asked at each step. Build the pattern once and it runs the same way at every site that uses it, with each site keeping its own contacts and its own escalation tree.
- Define the event type. A name, the source it comes from, the severity it takes, and the fields lifted out of the signal so the event can name what raised it and the group it belongs to.
- Set how the data is read. Thresholds and the conditions that count as a restore, and which value the operator sees first when the event opens.
- Route it. By site, area, severity and time of day, to the operator queue, to automated engagement, or to both.
- Write the response pattern. Ordered steps, the question asked at each one, the branch each answer takes, the contacts in order, the clocks and the reasons an event may be closed.
- Reuse it across sites. One pattern, each site's own contacts and escalation tree. A procedure improved at one site is a procedure improved everywhere it runs.
The workflow is not fixed at the moment the event opens
A static checklist assumes the situation holds still while somebody works through it. Three things change what the operator is asked next, and all of them happen mid event.
More signals come in
A second and third thing fail on the same plant. The procedure in front of the operator grows to match what is now happening rather than what was happening when it opened.
Somebody responds remotely
An engineer acknowledges, or acts on it from the field. The procedure moves on without the operator having to chase the answer.