Escalation workflows

An alert that nobody owns is a log line. Escalation workflows are the second half of alerting: turning a fired rule into an assigned piece of work, with a status, a history and a person responsible for it.

The work is carried on a response board, a kanban view with fixed stages and drag-and-drop movement. The state of a response becomes one glance at a board rather than a thread of messages that nobody can reconstruct later.

Every board runs the same sequence of stages: Issue, Impact Assessed, Next, In Progress, Review, Done, Monitoring and Feedback. Sharing one sequence is what makes responses comparable between incidents and straightforward to report on.

• Issue and Impact Assessed — the signal is recorded and somebody judges what it actually means.
• Next and In Progress — the immediate action is agreed, then carried out with an owner attached.
• Review and Done — the change is checked by a second person and completed.
• Monitoring and Feedback — the outcome is watched, and what was learned is fed back into the rules.
• Cards move freely between stages, and every move is attributed to a person.

Routing is decided where the rule is written, not reconstructed afterwards. A rule can notify the people who own the metric, open a card on a chosen board, or do both — and a board can be opened for a single event when one incident deserves its own space.

A card keeps the context that arrived with the signal: which rule fired, which location triggered it, and the message the rule author wrote. Categories and ownership are set on the card, so a response never lives only in somebody's head.

• Notify the owners in-app when the rule fires.
• Open a card on the board the response belongs to.
• Set an owner and a category on the card as it moves.
• Give a single event its own board when one incident deserves the space.

Every change to a card is recorded: who moved it, when, and with what note. Access is scoped by role, so the people who can close a response are the people who were given that responsibility.

That makes closure a fact rather than a claim. The history of a response survives the shift that lived through it, which is exactly what an incident review needs months later.

A response board is also an audit trail: stages, owners and notes are recorded as they happen.

When one event deserves more than a card, a board is opened for it alone and worked the same way. Stages, owners, notes, and the assignments for the people and feeds that cover it all sit in one place.

Because every board shares one model, a routine alert and a major event are tracked by the same means. That keeps small responses cheap to run and makes large ones visible to everyone who needs to see them.

Boards, rules and series are governed by the same role model. Access is scoped by role, so a person can work a response without being able to change the rules that produced it, and a site team sees its own board before anybody else's.

Security-relevant changes — who was given access, who altered a rule, who closed a card — are written to an audit log. Where several teams share the platform, that record is what makes shared access defensible rather than a matter of trust.

• Roles decide who can read a series, change a rule, or close a card.
• Hierarchical groups let a parent team see everything its units see.
• Logins, role changes and rule changes are recorded in the audit log.

Pick one recurring alert your team already handles by hand, and route it to a board. The first week shows which stages are actually used, who needs to be on the board, and which rules should simply notify instead.

The board does not have to match how you would draw the process on a whiteboard. Starting from the stage people really move cards through is faster than designing a perfect workflow first and discovering it is unused.

• Route one recurring alert to a board and leave the rest untouched.
• Name an owner for each stage you expect to use.
• Review after a month which rules should keep notifying.