Process Mining for Your Own Automations
Process mining is normally a separate enterprise product line — Celonis, UiPath Process Mining — sold to ops teams analyzing human-driven processes. Workflow-worker ships a version of it for automations you've already built.
If you've never heard the term "process mining," you're not alone — it's a category most people outside enterprise operations have never had reason to learn, because it's normally sold as its own separate, expensive product line. Celonis and UiPath Process Mining are the names that dominate that category, and they're typically bought by large operations teams to answer a specific, hard question about human-driven business processes: what is actually happening, step by step, versus what the process documentation says should be happening.
Piskes' workflow-worker ships a version of that same idea — GET /workflows/:id/process — built for automations you've already created, not human processes you're trying to reverse-engineer from log files.
Why this is a genuinely uncommon thing to bundle in
Most workflow and automation tools — Zapier, Make, n8n — give you a run history. You can see that a workflow ran, when, and whether it succeeded or failed. That's execution logging, and it's valuable, but it's not process mining. Process mining asks a different question: not "did this run succeed," but "what does the actual, observed pattern of how this workflow executes over time look like, and does that pattern match the process you designed?"
That distinction is the entire reason process mining exists as its own discipline in the enterprise world. A designed process — the flowchart, the documented steps — is an intention. The mined process — reconstructed from what actually happened, run after run — is a fact. The two drift apart more often than most people expect, and the drift is usually invisible until someone goes looking for it specifically.
What drift looks like in a workflow you built yourself
Consider a workflow you designed with a clean, linear intention: a form submission triggers a lead-qualification step, which branches into either a "notify sales" path or a "add to nurture sequence" path. That's the design. Over months of real runs, the actual pattern might look different in ways you'd never notice from a run-history view alone: maybe 40% of runs are hitting a retry on the qualification step before succeeding, which means a dependency is flakier than you think. Maybe the "notify sales" branch, which you assumed was the common case, is actually taken on only 12% of runs — meaning your lead flow is mostly nurture-sequence traffic, a fact that might change how you'd prioritize fixing either branch. None of that shows up in "did the run succeed" logging. It only shows up when you look at the aggregate, observed pattern across every run.
What the actual answer looks like: designed vs. observed
The process-mining view on a workflow reconstructs that observed pattern directly from execution history and puts it next to the design you built. The value isn't in any single run — it's in the aggregate. A step that looks fine in isolation on any given run can turn out, across hundreds of runs, to be a chronic bottleneck, an unexpectedly common failure point, or a branch that almost never fires the way you assumed it would when you built it. Those are exactly the kinds of facts that are structurally invisible to a per-run status view, because no individual run looks wrong — it's only the pattern across many runs that tells the real story.
Who this is actually for
This is deliberately not a developer-facing debugging tool, even though it lives inside a technical product. The audience that gets the most out of it is closer to an operations lead than an engineer: someone responsible for whether a business process is working well, not just whether the code executing it throws errors. A developer asks "did step 4 fail and why." An ops lead asks "is this the process we actually want to be running, now that I can see what it's actually doing" — and that second question is the one process mining answers.
Why this is worth taking seriously as a differentiator
Bundling process mining into a workflow tool rather than selling it as a separate product is unusual enough that it's worth naming directly: this is a feature category most competitors in the small-business and mid-market automation space don't offer at all, because it normally requires a dedicated analytics product built around ingesting process logs from other systems. Here, it doesn't need a separate ingestion pipeline, because the workflow engine already has the execution history — the process-mining view is a different way of looking at data the platform was already collecting.
The honest caveat
A process-mining view is only as useful as your willingness to actually look at it and act on what it shows you — it won't fix a badly designed workflow on its own, and it's not a substitute for the design work of deciding what a process should look like in the first place. What it does is remove the guesswork from knowing what a process actually does look like today, which is usually the harder half of that problem, and the half most tools don't even attempt to answer.