What Automated Process Discovery Is and Why It Matters

Automated process discovery is software that captures how work happens, from system event logs or desktop-level observation of screen activity, and generates as-is process maps with process variants, plus ranked automation candidates, without interviews or workshops. McKinsey’s “State of AI 2025” found that only 39% of organizations surveyed in mid-2025 reported any enterprise-level EBIT impact from AI, and that most had not yet redesigned workflows around AI and agentic capabilities (McKinsey, 2025). Workflow redesign depends on knowing how work runs, and a bot or agent built from a documented flow fails on the variants the documentation never recorded.

The failure usually appears in production rather than in design review. A claims bot that handled the tested path stalls on the undocumented ways adjusters reconcile a policy screen with an email attachment, and the delivery team absorbs the maintenance load. Before anyone writes bot logic, the delivery team can replace that guesswork with observed records of process variants and exception paths, including each handoff.

What is automated process discovery?

Automated process discovery is the automatic reconstruction of a process model from recorded execution data, either event logs written by enterprise systems or desktop-level observation of the applications people use to complete a case. The output describes what happened in the work, and it differs from a target-state design produced in a workshop.

Two data sources feed it, and the choice between them determines what the resulting map can show:

• System event logs: Enterprise resource planning (ERP), customer relationship management (CRM), workflow, and ticketing systems write records that carry a case identifier and an activity name with a timestamp. Log-based discovery stitches those records into end-to-end models of work that runs inside instrumented systems.
• Desktop activity: A lightweight sensor on workforce devices records screen activity, including application switches and interface actions, across mainframes, virtual desktops, web applications, spreadsheets, and office tools. Observation-based discovery reconstructs the micro-steps that no backend system logs, including handoffs between applications that share no data layer.

Outputs: Both sources yield the same families of output: end-to-end process maps, process variants ranked by frequency, execution metrics such as processing time and rework, and a scored list of automation candidates. Observation-based tools add cross-application handoffs and spreadsheet workarounds. They also capture exception paths that event logs cannot see.

Documentation gaps: Interviews and workshops record what domain experts can recall and choose to share. Saito and Iimura analyzed 2 years of events from an industrial workflow system and found that 46% of the observed process patterns had no counterpart in the documentation (Saito and Iimura, 2025). Those undocumented patterns are the ones a bot developer never receives in the requirements package.

Scaling barrier: The gap between knowing a process is fragmented and measuring it is a recurring reason automation programs fail. Deloitte’s 2022 intelligent automation survey ranked process fragmentation as the top barrier to scaling, yet only 23% of respondents used process mining to address it (Deloitte, 2022).

How automated process discovery works, step by step

Discovery runs in 5 stages: capture raw execution data, normalize it to a common schema, segment it into cases or task instances, classify and cluster the activities, and assemble the result into a map with variants and metrics. The capture stage differs by data source; the later stages converge.

1. Capture: Log-based tools extract event records through connectors to ERP and CRM systems. They also connect to workflow databases. Desktop agents record screen activity and interface actions on the workstation; several apply optical character recognition (OCR) and computer vision with redaction rules on the device or at a site gateway before anything is transmitted.
2. Normalize: Event logs follow IEEE 1849-2023, the eXtensible Event Stream (XES) standard, an active standard published in September 2023 that defines a tag-based grammar for logs organized as traces of timestamped events with attributes (IEEE SA, 2023). Desktop interaction records carry no case identifier, so the tool maps each action to a timestamp and an interface element with its values before any analysis can begin.
3. Segment: A raw click sequence indicates neither a process-level activity nor a specific execution. Segmentation algorithms cut the stream into task instances using repeated patterns or control-flow back-edges. Another method uses density-based online clustering to assign each incoming event to a known task type.
4. Classify and cluster: Computer vision identifies which application and screen is on display. OCR reads field labels and values, and clustering groups equivalent actions across users into a single activity node. Some tools pair neural pattern recognition with explicit rules so an analyst can trace why an action received its classification.
5. Assemble: The classified activities become an end-to-end map with variant frequencies, processing times, wait times, and rework loops. Tools that keep capturing after the first map can compare current execution against that baseline and flag drift.

Teams that continue observation across many processes use discovery tools to assemble a continuously updated graph of people, applications, tasks, decisions, and outcomes rather than a static diagram. The Context Graph of Work is 1 implementation of that structure.

Process discovery vs process mining vs task mining

The 3 terms separate by data source and scope, and the confusion comes from the word “discovery” meaning different things in academic and buyer usage. The table compares them on the 3 dimensions that drive a tool decision:

How the 3 terms differ by data source, scope, and deployment

In the academic literature the term is narrow. The 2012 “Process Mining Manifesto” defines process mining as extracting knowledge from event logs and names automated process discovery as 1 of its 3 basic types, alongside conformance checking and enhancement (IEEE Task Force on Process Mining, 2012).

Buyer and analyst usage widened it. HFS Research’s 2023 Horizons assessment defines process mining as “Application event log analysis” with a “Macro view” and process discovery as “Desktop user activity analysis” with a “Granular, task view” (HFS Research, 2023).

Process intelligence is the umbrella term Gartner adopted when it titled its 2026 assessment “Magic Quadrant for Process Intelligence Platforms.” Gartner’s 2026 market definition lists event-log process mining among the mandatory features and names task mining without making it mandatory (Gartner, 2026). A platform can therefore qualify as process intelligence while capturing nothing from the desktop.

When to use automated process discovery

Use log-based discovery when the process runs inside instrumented systems and observation-based discovery when the work crosses applications that write no shared event layer. Use both when an ERP-logged process hides task-level effort. Teams choose the method based on where the work happens.

• Logs suffice: The process runs end to end within well-instrumented ERP, CRM, or service management systems, the records already carry case and activity attributes with timestamps, the organization has data engineering capacity for connector setup, and the primary need is conformance checking against a documented model.
• Desktop observation required: Material work occurs in mainframes, VDI, or Citrix sessions without accessible logs, the process spans several applications with no single system of record, spreadsheet and email workarounds carry real volume, or a regulated workflow requires evidence of the human decision points and not only the system entries.
• Hybrid worth the cost: An ERP-logged process shows long cycle times between logged events and the team needs to know what people do in those gaps. Pair log-based mining for the end-to-end skeleton with desktop observation for the task detail; neither source is complete on its own.

Regulated, legacy-heavy workflows fall into the second and third cases. A Know Your Customer (KYC) review enters through an onboarding queue, moves into a core banking screen for identity verification, and stalls when the analyst exports a screening hit list to a spreadsheet to compare it against a sanctions result that arrived by email. The event log records the queue entry and the final disposition; only desktop observation records the spreadsheet step, its duration, and the exception path to a compliance escalation.

What you get out of it: Process maps, variants, and an automation roadmap

A completed discovery delivers 4 artifacts: end-to-end process maps, variant analysis, execution metrics, and a scored automation roadmap. The delivery team uses variant analysis and execution metrics to decide whether a candidate is build-ready.

• End-to-end maps: Maps show the applications and roles involved in a case from arrival to closure, including each handoff.
• Variant analysis: Analysis lists every observed execution path with its frequency and duration. A solution architect uses it to determine how many branches the automation must handle and which ones carry enough volume to justify coverage.

Execution metrics quantify processing time, wait time, rework, and cost per case, so the business case rests on measured effort rather than on estimates from a workshop.

Skan AI Intelligence produces those 3 artifacts from desktop-level observation as end-to-end process flows, variant analysis, and execution metrics, and adds bottleneck detection, drift detection, benchmarks, and opportunity analysis. Drift detection is the artifact an automation owner rarely gets from a point-in-time assessment; it flags an upstream process change before a deployed bot starts failing on it.

Skan AI Blueprint turns the opportunity analysis into a prioritized roadmap ranked by measurable business impact, with each opportunity classified as fit for agentic automation, augmentation, or continued human execution. It delivers that roadmap in weeks, not months.

Teams build the roadmap using a scoring model that separates bot work from agent work. That scoring, and its use in automation discovery planning, is covered next.

How discovery picks automation candidates for RPA and AI agents

Teams use a sound scoring model to separate deterministic work from work that needs context and judgment, scoring both independently of any execution platform. An observation tool measures rule density and exception frequency from captured execution. Analysts also assess judgment requirements using that evidence.

McKinsey’s “One year of agentic AI” states the routing rule plainly: “If the task is rule based and repetitive, with structured input (say, data entry), use rule-based automation,” and “If the task involves multistep decision-making and has a long tail of highly variable inputs and contexts, use AI agents” (McKinsey, 2025). The same piece warns that agents applied to low-variance, standardized workflows add complexity and uncertainty rather than value.

Pilots stall when teams base that routing decision on opinion instead of observed data. Gartner projects that over 40% of agentic AI projects will be canceled by the end of 2027 “due to escalating costs, unclear business value or inadequate risk controls,” and describes most current projects as early experiments that are “often misapplied” (Gartner, 2025). Teams that rank an automation backlog by stakeholder lobbying repeat the same pattern on the RPA side: they build bots for marginal processes while leaving high-volume exception-heavy work untouched.

• Platform-bundled scoring: Scoring bundled with an RPA platform tends to route every finding into that platform’s build pipeline.
• Vendor-neutral scoring: Automation Explorer scores each observed task twice, with a separate RPA Opportunity Score for rule-bound, repetitive work and an Agentic Automation Score for work that requires context-sensitive reasoning or exception handling. The scores are vendor-neutral, so the delivery team routes candidates to its existing RPA platform or workflow engine. It can also choose an agent framework it already runs.

Agentic AI programs need the same observed evidence in machine-usable form. Agent Operating Procedures (AOPs) encode workflow steps, decision rules, exception handling, policies, escalation thresholds, execution rules, and success criteria from observed work, so an agent inherits the exception paths a human handles instead of a generic prompt.

Skan AI Agents uses the Context Graph of Work and AOPs to define what an agent can do and when it must stop. It also defines when a human must decide. For candidates that score high on the agentic side, teams use that bounded procedure to move from a pilot into governed production.

Is desktop capture a privacy or surveillance problem?

Desktop capture passes privacy review when the unit of analysis is the process rather than the person and protected data is redacted before it leaves the customer perimeter. Employers must also settle the legal basis and employee representation steps before installing the first sensor. Teams that skip any of these conditions stall in legal review or in the works council.

Consent is the wrong foundation in Europe. The European Data Protection Board’s consent guidelines state that employees are unlikely to be able to refuse consent without fear of detriment, so for most workplace processing the lawful basis “cannot and should not be the consent of the employees” (EDPB, 2020). Employers instead rely on legitimate interest under GDPR Article 6(1)(f), document necessity and proportionality, and complete a data protection impact assessment under Article 35 before processing begins.

Works councils hold a formal role in Germany. Under § 87(1) no. 6 of the Works Constitution Act (BetrVG), the works council co-determines the introduction of technical devices designed to oversee employee conduct or performance (BetrVG, 2024). The Federal Labour Court reads “designed to” as objectively suitable for that purpose, regardless of the employer’s intent, so a discovery sensor falls inside the co-determination right even when no individual is ever assessed.

Regulators penalize individual measurement, and the distinction matters in the design. In February 2025 the French regulator CNIL published a EUR 40,000 fine against a real-estate company whose software flagged inactivity and took screenshots at intervals, finding the practice “particularly intrusive” with no Article 6 basis and no impact assessment (CNIL, 2025). Process observation aggregates actions into activity and variant statistics across a role, and the deployment documentation should state that boundary in writing.

• Healthcare: Healthcare organizations must apply the HIPAA minimum necessary standard. A vendor that receives protected health information (PHI) on a covered entity’s behalf is a business associate and needs a business associate agreement; the practical control is redaction at the point of capture so PHI never leaves the environment.
• Assurance: A SOC 2 Type 2 report is an attestation of control design and operating effectiveness over a stated period. Evaluators should request the report and its period rather than accept a compliance label.

Skan AI applies privacy by design through Skan PRISM, an on-premises privacy and information security gateway that performs pixel-level redaction before protected information can leave the customer environment. Raw screen data remains inside the customer-controlled perimeter, and email content and keystrokes are never captured.

Deployment can be Skan-hosted or private-cloud. A fully customer-hosted model supports data residency requirements. Request current assurance documentation for ISO/IEC 27001, ISO 42001, SOC 2 Type 2, PCI DSS, HIPAA, GDPR, CCPA, and TrustArc.

Tool comparison: Who does log-based, who does observation-based

Vendors sort into log-based platforms that added desktop capture and observation-based tools that lead with the desktop, and the practical differences concern where capture and redaction happen. Buyers also need to compare the exports. The table draws on each vendor’s current documentation:

Discovery tools by data source, deployment model, and output

Use the table to evaluate capture and privacy controls:

• Redaction location: Ask where redaction executes; on-device or on-premises redaction keeps protected data inside the perimeter, while cloud-side redaction means raw captures transit outside it.
• Capture frequency: Ask whether desktop capture is continuous or triggered per user action, because a triggered recorder produces episodic samples rather than a complete baseline.

Also ask for the method. None of the vendor documentation reviewed for this article names its clustering algorithm or computer vision model. It does not name an interface-element detection method either, so a proof of concept on 1 of your own exception-heavy processes is the only reliable test of classification accuracy. A buyer running Nintex Process Discovery should also confirm the migration path before the 2027 end-of-life date.

A worked example: Discovering an invoice workflow in weeks

An accounts payable workflow at an insurer’s shared services center illustrates the full sequence, from sensor deployment to a scored candidate list, within a few weeks. The process looks simple on paper: invoice arrives, clerk keys it, system matches it, approver signs off, payment runs.

Observation shows what the paper version omits. Invoices arrive as PDF attachments in a shared mailbox or as uploads through a supplier portal. Clerks also receive scanned paper.

A clerk reads each invoice and keys header and line data into the ERP, then triggers a 3-way match against the purchase order and goods receipt. When the match fails on price or quantity, the clerk emails the buyer, parks the invoice in a spreadsheet tracker, and re-keys the correction days later.

Non-PO invoices take a separate route through general ledger coding and a manual approval chase.

Expect the variant count to be large. An analysis of the BPI Challenge 2019 purchase-to-pay log counted 7,832 variants among 221,010 3-way-match cases where the invoice arrived before the goods receipt (ICPM, 2019). A bot designed from the single documented path covers 1 of those variants.

Skan AI Intelligence maps each variant’s frequency and duration, separating processing time from wait time so the team can locate delays. APQC’s open standards benchmark puts the median cycle time from invoice receipt to payment at 15 days (APQC, 2025); the team uses observed data to measure time in the email loop with the buyer and in the spreadsheet tracker, where no system records anything.

The team then sorts the variants by score:

• RPA: PO-backed invoices with a clean match score high on the RPA Opportunity Score: fixed rules for structured input, with few exceptions.
• Agentic automation: Non-PO invoices that need coding judgment and correspondence with the vendor score high on the Agentic Automation Score.

Disputed invoices that require contract interpretation stay with a human.

Hours saved come from observed handling time per variant multiplied by annual volume, which Skan AI Blueprint ranks into a roadmap with the business value of each opportunity. The delivery team then receives the top candidates as observed process definitions with every branch enumerated. Using those definitions, the team shortens the requirements phase and addresses variants that would otherwise surface as production incidents.

Related concepts

Four concepts extend automated process discovery from a one-time map into an operating input for automation delivery and governance, and each has a dedicated Blog post on the Skan AI site.

• Context Graph of Work: The Context Graph of Work is a continuously updated property graph that connects people, applications, tasks, decisions, policies, outcomes, relationships, sequences, and governance constraints from observed activity. It captures dependencies, cross-system handoffs, documented-process gaps, and exception patterns that a static process map cannot hold.
• Digital twin of operations: A digital twin of operations is a descriptive metaphor for the Context Graph of Work, and it describes a model that reflects current execution rather than a design captured at a single point in time.
• Agent Operating Procedures: AOPs are machine-usable representations of observed work produced through the observation-to-agent pipeline, which converts observed work into governed agent behavior with policy controls, evaluation against human baselines, and performance benchmarking.
• Continuous controls monitoring: Teams use observation that continues after discovery to detect deviations from approved procedures and generate alerts without system integrations, which applies to anti-money laundering (AML), KYC, HIPAA, and segregation of duties (SOD) requirements.
• Task mining: Task mining is the category term for desktop-level capture of user interactions. Everest Group assesses it separately from process mining as Digital Interaction Intelligence, and the capture mechanism it describes is the same desktop data that observation-based discovery depends on.