A useful rollback test proves more than whether an old routing rule can be switched back on. It must show that open requests remain accounted for, ownership is clear, priority rules behave as expected, and the team can recognize when the rollback is complete. Run the rehearsal in a test environment or on a deliberately small, reversible slice of work.
Define the change and the safe state
Write down exactly what is changing: classification rules, queue membership, priority logic, automation, service-level timers, or agent instructions. Then identify the last known-good configuration by version or export, not by a vague label such as “the old setup.” The Microsoft operational security evidence guide describes a back-out plan as a documented way to restore the previous configuration, validate service availability, and identify who performs the procedure. Use that as a minimum standard even when the support operation is small.
Choose rollback triggers before the test starts. Examples include a rise in unassigned work, tickets entering the wrong queue, priority cases waiting beyond the agreed limit, duplicate assignments, or agents losing access to their queue. Do not invent a universal threshold. Use the team’s own normal range and service commitments.
Capture a baseline that can be compared
Record the current routing configuration and a short baseline window. Useful measurements include assigned and unassigned work, longest wait time, queue priority, and available agents. Those fields are exposed in Microsoft’s record-routing queue report, but the same ideas can be collected from another platform. Preserve the query, time window, time zone, and filters so the after-test view is comparable.
Create a small test set covering ordinary questions, urgent cases, ambiguous requests, reopened work, and a request that must move between teams. Give each item a harmless marker and an expected route. Never use real sensitive customer details merely to make the test realistic.
Rehearse forward, trigger, and rollback
Apply the proposed change to the controlled scope. Confirm each test item reaches the expected queue and that agents can claim, transfer, and close it. Then introduce one planned failure, such as a deliberately mismatched rule in the test environment, or invoke the rollback trigger based on observed test results.
Restore the known-good configuration by following the written steps exactly. A person other than the author should be able to execute them. Record the start time, each action, errors, approvals, and the time normal routing is confirmed. If the operator has to improvise a missing command or search for a configuration file, the plan is not ready.
Google’s canarying guidance explains why a partial, time-limited rollout can reveal defects while limiting impact. The same principle applies here: test one queue, channel, or synthetic workload before exposing every incoming request. Do not overlap several routing experiments, because that makes the signal harder to interpret.
Verify the queue, not just the switch
After rollback, account for every test item by identifier. Confirm its current queue, owner, priority, status, and timestamps. Check that no request is stranded in a retired queue, silently duplicated, or reset to a lower priority. Compare the post-rollback metrics with the saved baseline and investigate differences rather than declaring success because the interface shows the old rule name.
Keep the restored system under observation for a defined period. The observation window should be long enough to exercise delayed automation, escalations, and scheduled rules. If a service-level clock was paused or recalculated, note that explicitly.
Close with evidence and ownership
Store the change record, configuration versions, test cases, measured results, rollback timeline, unresolved differences, and approval. Protect customer data and limit access to the evidence. Assign follow-up actions with owners and dates.
A passing rehearsal ends with a repeatable restoration, complete ticket accounting, expected queue behavior, and a clear decision record. A failed rehearsal is still valuable: keep the system on the known-good configuration, repair the plan, and test again before the production change.
Sources
- Microsoft 365 Certification sample evidence guide operational security — Microsoft Learn
- View and understand real-time analytics for record routing in the queue report — Microsoft Learn, June 26, 2026
- Canarying Releases — Google Site Reliability Engineering