Automated business process discovery uses recorded activity to help reconstruct how work actually moves through systems. Start with 4 evidence checks: the case being followed, the events recorded, their timing and the work missing from the data. A generated process map can reveal patterns, but it is not a complete account of every human decision.
Use discovery before automating a process whose real behaviour is unclear. The purpose is to understand the existing flow, its variations and exceptions. Automating the procedure described in a policy document without checking actual work can reproduce an inaccurate model more quickly.
How does process mining support discovery?
Microsoft’s Power Automate process-mining overview describes extracting event data from systems of record to visualise processes. Celonis’s process-mining explanation describes modelling and analysing how processes run. These are product and conceptual sources, not proof that a particular dataset accurately represents the organisation.
| Approach | Evidence it uses | Important limit |
|---|---|---|
| Interviews and workshops | People’s explanations and examples | Memory and perspective can differ |
| System-event analysis | Recorded transitions and timestamps | Unrecorded work may remain invisible |
| Task observation | Behaviour in a defined working context | The observed sample is not every situation |
| Combined discovery | Records interpreted alongside operational knowledge | Contradictions still need investigation |
The comparison is an original discovery framework. The approaches can complement one another. A system log may reveal a repeated return to an earlier stage, while staff explain that a required document is often missing. Neither should be discarded simply because the other looks more objective.
Distinguish process mining from a generic activity count. Counting transactions does not show the sequence and relationship of events within a case. The data needs to support the question being asked, and the analyst needs to understand what each event actually means.
What must be understood about event data?
Define the case. It might be an order, application or service request, depending on the workflow. A customer can have several cases, and a case can involve several people. Using the wrong identifier can merge unrelated journeys or split one journey into fragments.
Define the event. A timestamp for a database update may not mean that a business approval occurred. An import date may not be the original action date. Keep the source meaning alongside the analytical label instead of renaming every technical update as a meaningful process step.
Check ordering and time context. Systems can record different clocks or batch events later. A sequence that appears impossible may reflect logging behaviour rather than an impossible business action. Investigate those conditions before concluding that staff violated the process.
Identify missing work. Phone calls, paper checks and external decisions may occur without an event in the selected system. A neat map can omit precisely the step that explains a delay. Record that limitation and seek appropriate additional evidence.
How do you investigate a discovered variation?
Choose a specific pattern and trace a safe sample back to source records. A case returning to an earlier stage may indicate rework, a legitimate review or an error in the mapping. The visual alone cannot determine which explanation is correct.
Ask the people responsible for the work to examine the evidence. Use neutral questions about what happened rather than presenting the map as an accusation. Differences between the policy and the observed process can reveal a practical workaround or a control that is not being represented correctly.
Separate delay from fault. A long interval may involve an external dependency, a deliberate waiting period or missing data. Do not invent a universal threshold for what counts as unacceptable. Use the business’s actual commitments and the evidence available.
Use this original discovery evidence card:
| Field | What to record | Question it resolves |
|---|---|---|
| Case definition | Unit of work and identifier | Which events belong together? |
| Event meaning | Source action and analytical label | What actually happened? |
| Timing | Original clock and recording conditions | Is the sequence being interpreted correctly? |
| Coverage | Systems and manual steps included | What remains invisible? |
| Variation | Specific observed pattern | Is it rework, exception or data error? |
| Explanation | Supporting records and operational context | Which interpretations remain plausible? |
| Control | Rule that should remain true | What must automation preserve? |
| Next experiment | A bounded change and evidence | What would justify adopting it? |
The card is an original practical artefact. It connects a generated map to source evidence and an accountable decision. It does not declare a process compliant or authorise an automated action.
When is a process ready for automation?
Identify the part with a clear input, rule and result. A task involving unresolved judgement or contradictory source information may need assistance or better data before full automation. Do not treat every manual action as waste merely because software could perform something similar.
Define the exception route before activation. Someone must own a missing input, rejected action or failed integration. A process that automatically handles ordinary cases while silently losing unusual ones is not an improvement.
Test a repeated or interrupted action. The automation should recognise an existing result where appropriate and preserve the case reference. A user retry should not create a duplicate obligation merely because the first response was lost.
What privacy and operating boundaries matter?
Use the minimum data needed for the discovery question and obtain the appropriate authority for analysing it. System records and observed tasks can contain sensitive personal or commercial information. Product capability does not establish that every collection or use is permitted.
Retain a record of the dataset, transformation and definitions used. A future map may change because the source or extraction changed, rather than because the business process improved. Reproducibility helps distinguish those explanations.
Assign an owner for the improvement decision and review its actual effect. A visually simpler process is not automatically better if it removes a necessary check or moves work into an unrecorded channel.
See web development for related process integration. To explain a discovery requirement, get started with a redacted case example, relevant systems and the uncertainty that must be resolved before automation.
Record the precision of timestamps as well as their time zone. If several events share the same recorded time, the data may not establish their exact order. Preserve that uncertainty rather than inventing a sequence because a diagram requires one. The resulting limitation belongs beside any conclusion about waiting or repeated work.
Microsoft’s data-preparation reference distinguishes process-instance identifiers, activity names and event versus activity timestamps. A current-state table can omit the history needed to reconstruct a sequence. Check those fields and missing events before interpreting a mined diagram as complete work evidence.
By Spout Team. AI-assisted drafting by Codex using the linked primary sources.