Human overrides should expire
A manual override can rescue a stuck workflow, then quietly become permanent policy. Give overrides an owner, a reason, and an expiry so exceptions return to deliberate review.
On this page 5 sections
- Treat overrides as temporary exceptions, not silent policy changes.
- Record who changed what, why, and until when.
- Make expiry return the workflow to a visible, safe state.
A manual override feels like the fastest way to unblock a user. The trouble starts when the exception outlives the incident: a one-off setting remains in place, nobody remembers why, and the next person assumes it is intended behavior. I would design every override with an expiry from the start.
An override changes the operating rule#
Suppose a workflow normally routes a case for review when required information is missing. An operator bypasses that check because a specific case has an urgent deadline. The immediate action may be reasonable, but the system has now departed from its standard path.
That is more than a button click. It is a temporary policy change with a scope, a risk, and a future decision attached. If the product records only “override enabled,” it loses the context needed to decide whether the exception should continue.
A useful override record has five fields:
| Field | Question it answers |
|---|---|
| Scope | Which case, user, or workflow is affected? |
| Owner | Who is accountable for reviewing it? |
| Reason | What condition justified the exception? |
| Expiry | When does the exception stop applying? |
| Return state | What should happen after expiry? |
These fields make the exception legible to the next person. They also expose when an override is too broad: “all cases” may be a product change disguised as a workaround.
Make expiry a real state transition#
An expiry timestamp alone is not enough. At the deadline, the system needs a defined behavior. It might restore the prior rule, pause the affected workflow, or send the item to a review queue. Which choice is right depends on the consequence of reverting.
The important constraint is that expiry must not silently create a more dangerous state. If reverting a setting could interrupt a critical process, the product should warn the owner before the deadline and specify what happens if nobody responds.
For a low-risk formatting exception, automatic restoration may be fine. For a decision that changes what can be approved, expiry could instead move the case back to a pending state. The system should show the transition in the activity history, not make the user infer why behavior changed.
Keep extensions explicit#
Sometimes the exception is still needed when it expires. Let the owner extend it, but make the extension a new decision rather than a hidden reset of the clock.
A review card can show:
- the original reason and scope;
- what has happened under the override;
- the current expiry and return state;
- the options to end, extend, or replace it.
An extension should ask for a current reason and a new expiry. That small amount of friction distinguishes “still justified” from “nobody got around to cleaning it up.” If the same exception is repeatedly extended, surface that pattern as evidence that the standard workflow may need redesign. Do not automatically turn frequency into permission.
Separate emergency access from ordinary exceptions#
Some products need a way to act during an outage or urgent incident. That should not be conflated with a routine override. Emergency access may require stronger identity checks, narrower scope, immediate logging, and review after the event.
The product can still make it usable: state what the emergency action changes, who will be notified, and what recovery or review follows. A vague “break glass” control provides power without making its consequences clear.
For ordinary exceptions, the default path should remain easy to understand and auditable. For genuine emergencies, the path can be fast while leaving a clear record. Both need boundaries; urgency is not a reason to erase them.
Review the exception queue#
A practical weekly review does not need a complex dashboard. Start with a list of active overrides sorted by expiry, showing owner, scope, reason, age, and next action. Then ask three questions:
- Is the exception still needed for the stated reason?
- Is its scope still the smallest useful scope?
- Should the standard workflow change, or should this exception end?
The queue also reveals missing ownership. If nobody can decide whether an exception should continue, assign a responsible role before adding more overrides. Otherwise the system has created a permanent policy with no explicit approval.
My design rule: every override needs a named owner, a bounded scope, a reason that can be reviewed, an expiry, and a safe return state. If one of those is missing, it is not a controlled exception; it is an undocumented change to how the product works.