Chapter 27 — Deploy and validate an incident case workflow
Lesson map
Lesson 27 published. Map, example, EX079.
flowchart TD
N0["Learning outcomes and connection"]
N1["27.1 The state model"]
N2["27.2 Validating before deployment"]
N3["27.3 Lab T-27 synthetic : transition tests"]
N4["27.4 Deployment"]
N5["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX079"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["27.1 The state model"]
N2["27.2 Validating before deployment"]
N3["27.3 Lab T-27 synthetic : transition tests"]
N4["27.4 Deployment"]
N5["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX079"]
[Learning outcomes and connection]
|
v
[27.1 The state model]
|
v
[27.2 Validating before deployment]
|
v
[27.3 Lab T-27 synthetic : transition tests]
|
v
[27.4 Deployment]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX079]
Learning outcomes and connection
You will be able to (1) implement the case workflow as a state model with transition rules in the case tool; (2) validate it with automated tests before deployment; and (3) deploy it with training, a pilot and a rollback plan. Chapters 4, 17, 20 and 25 produced the data model, tool, checks and workflow design; now they go live.
27.1 The state model
Fernmoor's case states: new → triage → investigating → containing → recovering → review → closed, with closed-benign reachable from triage or investigating. Transition rules enforce the process: entering containing requires a recorded approval; closed-benign requires a triage note; closed requires a review record. Disallowed transitions (for example triage → containing without investigation, or containing → closed without recovery and review) are blocked or require an override with justification that is logged. Fernmoor's pilot showed the effect: record completeness rose, and only two overrides were needed, both justified.
27.2 Validating before deployment
Write tests: sequences of transitions with expected acceptance or rejection. Run them against a model of the rules and then against the configured tool in a test instance. This is the same discipline as testing a parser on known input (Chapter 3). Fernmoor's pilot found a defect that tests had missed: a case in recovering could not link a new IT change, which only appeared with the real tool configuration. It was fixed before rollout, and a test for that transition was added so the defect cannot return unnoticed. The final test suite runs against every later configuration change.
27.3 Lab T-27 (synthetic): transition tests
# Lab T-27: validate an incident case workflow against its state model
ALLOWED = {"new":{"triage"}, "triage":{"closed-benign","investigating"},
"investigating":{"containing","closed-benign"}, "containing":{"recovering"},
"recovering":{"review"}, "review":{"closed"}, "closed-benign":set(), "closed":set()}
REQUIRES = {"containing":"approval", "closed":"review_record", "closed-benign":"triage_note"}
def check(case, steps):
s="new"; errors=[]
for to,fields in steps:
if to not in ALLOWED[s]: errors.append(f"{s}->{to} not allowed")
need=REQUIRES.get(to)
if need and need not in fields: errors.append(f"{to} lacks {need}")
s=to
print(case, "OK" if not errors else "; ".join(errors), "| final:", s)
check("T1",[("triage",set()),("investigating",set()),("containing",{"approval"}),
("recovering",set()),("review",set()),("closed",{"review_record"})])
check("T2",[("triage",set()),("closed-benign",{"triage_note"})])
check("T3",[("triage",set()),("containing",set())])
check("T4",[("triage",set()),("investigating",set()),("containing",{"approval"}),("closed",set())])
Expected output:
T1 OK | final: closed
T2 OK | final: closed-benign
T3 triage->containing not allowed; containing lacks approval | final: containing
T4 containing->closed not allowed; closed lacks review_record | final: closed
T1 is a full S2 lifecycle and passes. T2 is a benign close and passes. T3 jumps from triage to containment without approval and fails on both rules. T4 skips recovery and review and closes without a review record — two violations. When the same tests were run against the configured tool in the test instance, T4 was accepted — the tool's rule for closed checked only the review field's presence, not the state order. The configuration was corrected and all four tests re-run; this is why tests run against the real configuration, not only the model.
27.4 Deployment
Plan: train all duty analysts and leads with a one-hour walkthrough and two practice cases in the test instance; pilot with one team for four weeks; measure record completeness (Chapter 20 checks) and analyst feedback; fix issues; then roll out. Rollback: keep the previous workflow configuration exportable and a documented switch-back procedure; open cases at the time of rollback are mapped state by state. Emergency override: the incident lead may force a transition with a justification; every override is reviewed weekly.
27.5 Worked example (synthetic): pilot results
Fictional. Four-week pilot with the Response Desk (23 cases): record completeness improved from 71% (previous quarter, same checks) to 96%; two overrides, both justified (a case reopened after closure; a duplicate merged). Analysts reported that the approval field was slow on mobile; it was made a one-tap selection from the on-call approver list. One defect: a case in recovering could not link a new IT change; fixed before rollout. Because the comparison is with a previous quarter and the team knew it was being observed, part of the improvement may not persist; completeness continues to be measured monthly.
27.6 Common errors and limits
- Rules so strict that analysts work outside the tool.
- Testing only the model, not the tool configuration.
- Deploying without training or a rollback.
- Before/after comparisons presented as proof without caveats.
Fernmoor's pilot handled these. Two overrides were enough for real exceptions, so analysts kept working in the tool; the tool configuration was tested as well as the model; training and rollback came before the rollout; and the reported completeness gain was presented with the caveat that a previous quarter and an observed team make the comparison weaker. Completeness continues to be measured monthly.
Exercises — chapter 27
Attempt each exercise before opening the worked results. Every case, organization, person, address and number in an exercise is synthetic unless a cited public source is named.
EX079 — New test. Steps: write two more test sequences for the lab — one valid path through closed-benign from investigating, one invalid reopen from closed. Predict output. Rubric: 3 = sequences and correct predicted output (OK; "closed->investigating not allowed"); 2 = one; 1 = attempted; 0 = none.
EX080 — Override policy. Steps: write the override rule. Rubric: 3 = who may override, justification required, logged, weekly review, reporting of override rate; 2 = no review; 1 = vague; 0 = none.
EX081 — Rollback plan. Steps: write a rollback plan for the workflow deployment. Rubric: 3 = trigger criteria, decision owner, configuration restore, open-case mapping, communication, verification; 2 = missing mapping; 1 = vague; 0 = none.
Chapter synthesis
Implement the workflow as a state model with enforced transitions, test it against the real configuration with known sequences, deploy with training, pilot, measured results and a rollback, and govern overrides openly.
Continue studying — chapter 27 of 30
← Chapter 26 · Course chapter index · Chapter 28 →
Continue to the next authored lesson.