EN 
Українська
Polski
Español
Deutsch
日本語
Italiano
Português (BR)
Français
العربية
Nederlands
中文
한국어
हिन्दी
Türkçe
Tiếng Việt
Русский
Bahasa Indonesia
فارسی
বাংলা
ไทย
Filipino
Kiswahili
اردو
Bahasa Melayu
தமிழ்
עברית
Ελληνικά
ਪੰਜਾਬੀ
አማርኛ
မြန်မာဘာသာ
ខ្មែរ
ქართული
नेपाली
Монгол хэл
Հայերեն
සිංහල
ລາວ
Čeština
Română
Magyar
Български
Svenska
Dansk
Suomi
Norsk
Slovenčina
Hrvatski
Српски
Slovenščina
Lietuvių
Latviešu
Eesti
Íslenska
Shqip
Македонски
Bosanski
Malti⚙️ RPA Workflow Automation — Bots on a Process Graph
Tasks flow through a business process graph as software bots execute rule-based steps and route exceptions to a human — watch throughput and queue depth live.
About RPA Workflow Automation
Robotic process automation (RPA) and its more capable cousin, intelligent business process automation (IBPA), replace the repetitive, rule-based steps of a business process — reading a field, checking it against a rule, entering it into a system of record — with software bots that execute the same steps tirelessly and consistently. But bots don't remove queueing: they change its shape. A process is still a graph of steps, each with limited capacity, and tasks still arrive unpredictably and still queue when a step is temporarily saturated. Understanding where bottlenecks form — and why adding capacity in the wrong place does nothing — is the core skill behind designing an automation programme that actually reduces cycle time rather than just moving the backlog.
This simulation models an eight-step invoice-processing workflow — from "Invoice received" through data extraction, validation, an automated match against a purchase order or a routed human review, approval, and payment scheduling — as a directed process graph rendered in 3D. Tasks (particles) are generated at a configurable, Poisson-distributed arrival rate, move along the graph's edges, and queue visibly at any node whose bot capacity is exceeded. At the Validation node, a configurable exception rate randomly diverts a fraction of tasks to a single-slot Human review node, standing in for the confidence threshold a real classifier applies. Live charts track throughput, average cycle time, per-node queue depth, and the straight-through vs human-review split, so you can watch queueing theory happen rather than just read about it.
Frequently Asked Questions
What is RPA, and how is it different from intelligent business process automation (IBPA)?
Robotic process automation (RPA) uses software "bots" that follow fixed, rule-based scripts to perform tasks a human would otherwise do at a keyboard — reading a field, copying a value, clicking a button — without understanding the content. Intelligent business process automation (IBPA) layers machine learning, OCR, and NLP on top of RPA so the system can handle unstructured inputs (a scanned invoice, a free-text email) and make judgement calls, escalating only genuinely ambiguous cases. This simulation models an IBPA-style pipeline: most steps are deterministic bot logic, but the Validation node uses a configurable exception rate to send a fraction of tasks to a human, standing in for the confidence threshold a real classifier would apply.
What does "straight-through processing" (STP) mean?
Straight-through processing describes a task that completes an entire workflow without any human touching it — in this simulation, any invoice that goes Validation → Match to PO rather than Validation → Human review. STP rate is a core KPI for finance and operations teams automating a process, because every task that needs a human costs far more in wall-clock time and headcount than one a bot clears alone. The straight-through vs human-review split shown live in the stats panel is exactly the number process-automation vendors quote in case studies.
Why do queues form even when average capacity looks like it should be enough?
This is the central, counter-intuitive result of queueing theory. Even if a node's average service rate exceeds its average arrival rate, tasks still queue because both arrivals and service times are random, not evenly spaced. A run of several tasks arriving close together, or one that happens to take much longer to process, creates a temporary backlog that takes time to drain — and that backlog compounds because a busy bot can't get a head start on the next task. The queue length grows non-linearly as utilisation (arrival rate ÷ capacity×service rate) approaches 1, which is why the Human review node in this simulation — with only one bot — backs up sharply even at a modest exception rate.
What does the exception rate represent in a real deployment?
In production RPA/IBPA systems, the exception rate is the fraction of cases where a bot's confidence score falls below a configured threshold, a business rule flags an anomaly (amount above a limit, missing PO match, duplicate invoice number), or the bot hits an unhandled state (a changed UI, a malformed field) and throws an error. Every exception is routed to a human queue for manual resolution. Lowering the confidence threshold increases straight-through processing but risks more silent errors reaching the ledger; raising it is safer but pushes more volume — and cost — onto people. The exception-rate slider here lets you see that trade-off play out as a queue, not just a percentage.
What is Little's Law, and how does it apply to the cycle-time number shown here?
Little's Law states that, in steady state, the average number of tasks in a system L equals the average arrival rate λ multiplied by the average time each task spends in the system W (L = λW). It holds for any queueing system regardless of the arrival or service distributions. In this simulation you can verify it directly: multiply the current arrival rate by the average cycle time shown in the stats panel, and it should track the total number of tasks in flight (queued plus being processed plus travelling) fairly closely once the system has run for a while.
Why does Human review become the bottleneck so quickly?
Human review is deliberately modelled with only one reviewer slot by default and a processing time roughly five times longer than the automated bot steps — which mirrors reality, since a person reading an exception case takes far longer than a bot copying a field. Even a modest exception rate concentrates a disproportionate amount of total work time onto that single slot, so its utilisation (and therefore its queue) rises much faster than any automated node's as you increase the exception-rate or arrival-rate sliders. This is exactly why real automation programmes obsess over shrinking the exception rate rather than just adding more bots elsewhere.
How do bot capacity and processing speed change throughput?
Bot capacity is the number of tasks a node can work on in parallel; processing speed scales how quickly each task is completed once it starts. Raising either one increases a node's service rate (capacity × 1/service-time), which lowers utilisation at that node and drains its queue. But a process graph is only as fast as its slowest node: adding bots to an already-idle node does nothing for overall throughput, while adding even one more bot to a saturated bottleneck node (usually Human review here) can produce an outsized drop in average cycle time — a direct illustration of the theory of constraints.
Why do task arrivals use random (Poisson-like) intervals instead of a fixed schedule?
Real invoices, claims, or support tickets do not arrive on a metronome — they arrive in bursts and lulls. Modelling arrivals with exponentially distributed inter-arrival times (a Poisson process) is the standard way to capture that unpredictability while keeping a single, tunable "arrival rate" parameter. This is what produces the queueing behaviour described above; a simulation with perfectly evenly spaced arrivals would almost never form a queue even at high utilisation, which would badly understate how backlogs form in real operations.
Tasks flow through a business process graph as software bots execute rule-based steps and route exceptions to a human.
3D · Three.js / WebGL renderer · 60 FPS target · runs fully client-side, no install