Workflow Automation Discovery: Five Questions Before You Build
Quick Answer
Workflow automation discovery answers five questions before development begins, not after: process truth, exceptions, volume, failure tolerance, and ownership. Each has a named owner and an evidence surface that is not memory. When two answers conflict, the one drawn from a system record outranks the one drawn from memory: the rule that prevents discovery from settling on the tidier answer instead of the true one.
Key Takeaways
Workflow automation discovery answers five questions before development begins, not after: process truth, exceptions, volume, failure tolerance, and ownership. Each has a named owner and an evidence surface that is not memory.
Process truth comes from step-by-step walkthroughs with the staff handling real completed items, not from workshops describing what the process is supposed to be. What is documented and what actually happens are usually different.
Exceptions belong in a register that tracks trigger, handling method, frequency, and business consequence. Exceptions are where automation programs fail because the exception path carries more logic than the main path, and it is invisible until it runs.
When two answers conflict, the one drawn from a system record outranks the one drawn from memory. This rule prevents discovery from settling on the tidier answer instead of the true one.
Discovery halts automation if exceptions keep growing on each review, no clear process owner emerges, or planned process changes make the current specification obsolete before the build lands. Automating a moving target is more expensive than waiting for it to stop.
Each has a named owner and an evidence surface that is not memory.
Why Discovery Comes Before Development
The distance between how a process is described and how it actually gets performed is where automation programs fail. The description is tidy. The execution has exceptions, workarounds, decisions made informally at the desk, and volumes nobody measured because they never had to. Discovery is what closes that distance before development starts and before requirements have been signed off against a version of the process that only exists on paper.
Five questions carry it. Each has a named owner, and each has an evidence surface that is not memory.
Question 1: Process Truth
What work actually happens when the process is performed? Documented in step-by-step walkthroughs with the staff handling real completed items, not workshops describing the intended process, and not reconstructions from procedure documents.
The mechanic is small: sit next to the person, follow one item from the point it enters the process to the point it leaves, and document what actually occurs. The corrected walkthrough is reviewed by the person observed. The output is the process as it is, not as it is described to be, and the two are usually different in ways that matter for the automation design.
Question 2: Exceptions
Real departures from the standard steps, captured in an exception register that names the trigger, the handling method, the frequency, and the business consequence. This is the question that determines whether the automation program lands or drifts, because the exception path usually carries more logic than the main path and is invisible until it runs.
Exceptions belong in a register that tracks trigger, handling method, frequency, and business consequence.
Exceptions come from two sources: the person doing the work knows they happen because they handled the last one, and the system records show the pattern because handling exceptions produces different data than handling the standard case. Both sources have to be read; workshop lists of exceptions consistently underestimate the count.
30 Years of Automating Regulated Business Processes
i3solutions has automated enterprise processes for 30 years, with senior, 100% US-based teams and delivery standards built for compliance-bound environments.
Actual arrival counts per period, arrival clustering patterns, and concurrent items in flight. Drawn from system records, not estimates. “How many do we handle a day” is a question the record answers precisely and memory answers approximately, and the two answers usually differ by a factor that matters for capacity planning.
Three sub-questions live here. What is the average rate? What is the peak rate (the month-end close, the fiscal-year deadline, the seasonal surge) because capacity planned for the average fails on the day that matters. And what does concurrency look like (how many items are in flight simultaneously) because that number sizes the parallelism the automation needs.
Question 4: Failure Tolerance
What are the business impacts of a wrong outcome, signed by an accountable leader? Failure tolerance addresses cost of wrong output, notification requirements when things go wrong, and the acceptable duration of degraded operation before manual intervention is required.
The signature matters because failure tolerance is a business decision, not a technical one. “The automation can afford to be down for four hours before somebody has to pick up the phone” is a claim only the process owner is qualified to make, and it is the claim the escalation design depends on.
Question 5: Ownership
Named individuals against four roles: process accountability, approvals at decision points, data ownership, and post-launch responsibility. Each is a person, not a committee, and each is somebody who can act without escalation.
Ownership is the question that determines whether the automation still runs a year after launch. An automation with no owner is an automation nobody watches, and nobody notices when its assumptions stop matching reality.
Read It, Do Not Recall It
Two rules govern discovery output. First: read it, do not recall it. Every quantitative answer comes from a system record; every qualitative answer comes from observation of the current process, not description of the intended one. Second: when two answers conflict, the one drawn from a system record outranks the one drawn from memory. This prevents discovery from settling on the tidier answer instead of the true one.
When Discovery Halts Automation
Three situations stop the automation project, and recognizing them early saves the budget from being spent on a build that would not have landed.
Three situations stop the automation project, and recognizing them early saves the budget.
Exceptions keep growing on each review. The exception register that gets longer every session is a register of a process that is not yet stable enough to automate. The next automation input is process work, not development.
No clear process owner emerges. An automation without a named owner is an automation nobody defends when its assumptions break. Finding the owner is a prerequisite, not a project artifact.
Planned process changes make the current specification obsolete. Automating a process that is scheduled to change in six months is buying obsolescence. Either wait for the change or scope the automation against the post-change state.
How i3solutions Runs Workflow Automation Discovery
i3solutions has delivered on the Microsoft stack since 1997, with senior, 100 percent US-based teams. Workflow discovery runs the same discipline every governance-first program does: read the process from the desk rather than the description, count the volume from records rather than estimates, register the exceptions before they surface in production, and refuse to automate a moving target, however much pressure is on the calendar.
Michael Branson
Founder/COO
Michael Branson co-founded i3solutions 30 years ago and brings executive, operational, and technical perspective to organizations working in complex, secure, and mission-critical environments. His insights focus on business process consulting, automation, data analytics, collaboration, secure operating models, and the operational discipline required to turn technology investments into practical business systems with measurable value.
Five, each with a named owner and an evidence surface that is not memory. Process truth (walkthroughs with staff handling real completed items). Exceptions (a register naming trigger, handling method, frequency, business consequence). Volume (arrival counts, clustering, concurrency drawn from system records). Failure tolerance (business impact of wrong outcomes, signed by accountable leader). Ownership (named individuals for process, approvals, data, post-launch responsibility).
By sitting next to the person doing the work and following one item from entry to exit, not through workshops describing what the process is supposed to be, and not from procedure documents. The corrected walkthrough is reviewed by the person observed. The output is the process as it is, not as it is described to be, and the two are usually different in ways that matter for the automation design.
Because the exception path usually carries more logic than the main path and is invisible until it runs. Exceptions come from two sources: the person doing the work knows they happen because they handled the last one, and the system records show the pattern because handling exceptions produces different data than handling the standard case. Both sources have to be read; workshop lists consistently underestimate the count.
From system records, not estimates. Average rate, peak rate (month-end, fiscal year, seasonal surge: capacity planned for the average fails on the day that matters), and concurrent items in flight (which sizes the parallelism the automation needs). 'How many do we handle a day' is a question the record answers precisely and memory answers approximately.
When two answers conflict during discovery, the one drawn from a system record outranks the one drawn from memory. This rule prevents discovery from settling on the tidier answer instead of the true one, and it is why every quantitative answer comes from a system record and every qualitative answer comes from observation of the current process rather than description of the intended one.
Three situations. Exceptions keep growing on each review: the register that gets longer every session is a process not yet stable enough to automate. No clear process owner emerges: automation without a named owner has nobody who defends it when assumptions break. Planned process changes make the current specification obsolete before the build lands: automating a moving target is more expensive than waiting for it to stop.
The Flow That Fails at 2am Has No One on Call
When automation runs business processes, ownership, error handling, and monitoring are production requirements. i3solutions' senior workflow advisors work with IT leaders ready to put engineering discipline around the automation the business already depends on.
