The operating problem
Most process diagrams show a clean sequence: request, review, approve, complete. Real work includes missing information, rejected approvals, unavailable stock, duplicated requests, device failures, customer changes, absent staff and records that cannot move forward. When software models only the ideal route, users return to email and WhatsApp the first time reality diverges.
Engineering judgement tied to operating evidence.
Founder and software/electronics engineer at INESSOFT. Reviewed against current INESSOFT delivery practice and operating evidence.
Published 02 Jul 2026 · Last reviewed 02 Jul 2026Model business states, not screen steps
A user opening a page or clicking next is not necessarily a meaningful state change. States should answer what is true about the record: awaiting review, approved, allocated, in progress, blocked, rejected, completed or cancelled. Screens and buttons then support controlled transitions between those conditions.
- Use names understood by operational users.
- Keep technical processing states separate where needed.
- Avoid one generic status field that combines unrelated meanings.
Every transition needs an owner and prerequisites
A transition should identify who may perform it, which fields or evidence are required and what downstream action follows. This prevents the system from becoming a passive form collection where records appear complete despite missing approvals or documents.
- Define role and organisation boundaries.
- Validate required evidence at the transition point.
- Record who acted, when and under which rule version.
Blocked is a legitimate state
Users often hide blocked work by leaving it in progress or adding notes. A visible blocked state should capture reason, owner and next action. Management can then distinguish active work from records that need intervention.
- Use controlled reason categories plus explanatory notes.
- Track the age of blocked records.
- Allow escalation without silently reassigning responsibility.
Correction must preserve history
Operational records will contain mistakes. Preventing all editing is impractical; allowing unrestricted overwriting destroys accountability. Corrections should record old value, new value, user, time and reason where consequence requires it.
- Differentiate normal edits from formal corrections.
- Protect machine or source-system evidence from human overwrite.
- Use effective dates or versions for rules and documents.
Notifications are not the workflow
Email and messaging can alert users, but the authoritative work queue must remain in the system. Otherwise completion, reassignment and exceptions disappear into personal inboxes. Notifications should point to owned records and degrade safely when delivery fails.
- Store task and status independently from notification delivery.
- Avoid sending sensitive operational detail unnecessarily.
- Provide digest or escalation patterns for persistent work.
Exception data improves the process
Once reasons and recovery paths are structured, management can see where work repeatedly stalls. The system becomes a source of process-improvement evidence rather than merely a transaction log.
- Report exception frequency, age and recurrence.
- Review common overrides as candidates for rule change.
- Distinguish training problems from system or policy problems.
Use the operating signal to choose the next action.
The same symptom can justify a custom system, a smaller integration, a stabilisation phase or no build at all. The decision should follow evidence rather than enthusiasm for a particular technology.
Work follows one person and errors have low consequence.
A simple task list may be enough.
Avoid overengineering a state machine.
Records cross departments or require approvals.
Explicit states and ownership are justified.
Model transitions, permissions and audit evidence.
Exceptions are frequent but managed in notes.
The system hides operational risk.
Create blocked/review states and controlled reason categories.
Users repeatedly bypass the application after unusual events.
Exception design is incomplete.
Observe real failures and add recovery paths before more features.
Evidence that the current approach is becoming risky.
- A single status field has dozens of loosely defined values.
- Users change status without required evidence or permissions.
- Blocked work is indistinguishable from active work.
- Corrections overwrite prior values with no reason.
- Email replies become the only record of approval or rejection.
What to clarify before commissioning work.
- List meaningful business states and who owns each.
- Define allowed transitions and prerequisites.
- Identify likely exceptions before implementation.
- Create blocked, rejected, cancelled and correction paths.
- Keep notifications secondary to system queues.
- Report exception volume, age and resolution patterns.
Case studies behind the lesson.
These links provide system context, architecture, workflows and engineering decisions connected to the article.
Questions that usually appear during scoping.
Does every workflow need a formal state machine?
No. Formal modelling is most valuable where ownership, approvals, exception handling or auditability have material consequences.
Should users be allowed to reopen completed work?
Where the business requires it, reopening should be an explicit transition with permission, reason and history rather than a silent status edit.
Can email approvals remain valid?
They can be integrated or recorded, but the operational system should preserve the authoritative decision and associated evidence.
How many exception categories should be created?
Start with categories that change ownership or recovery action. Avoid a huge taxonomy before real usage provides evidence.