Time and cost
Two quantities, two different ways of aggregating.
The three numbers of a step
| Input field | Meaning | Example |
|---|---|---|
| Work minutes | Time a real person actually spends doing it | Signing one file: 5 minutes |
| Waiting minutes | The case sits there, nobody has touched it | Waiting for the director to be free: 1.410 minutes (almost a day) |
| Cost | Money for one run of that step | 600.000 VND |
In an approval process, waiting time is usually many times larger than work time. Merge the two into one field and the report either lies about the deadline or lies about the effort. Split them and you immediately have the two numbers every improvement proposal needs: how long the process takes and how many person-hours it burns.
The two aggregate numbers
- Elapsed time — from the moment a case starts to the moment it is done. This is the number you use to promise a deadline to a customer.
- Actual effort — the total minutes people spend. This is the number you use to work out how many staff you need.
Inside a parallel block these two numbers follow two different rules:
| Sequential | Parallel | |
|---|---|---|
| Elapsed time | Sum | MAX — the branches overlap each other |
| Effort | Sum | SUM — each branch has a real person sitting and working |
| Cost | Sum | SUM |
Effort divided by elapsed time. Internal approval processes usually land somewhere around 2–10%: meaning more than 90% of the time the case is just waiting. This is usually where you can cut the most without anyone having to work faster.
Steps that run several instances
Some steps run several times within one and the same pass: signing 20 contracts, approving 8 line items, sending letters to 50 customers. In the step's Details dialog, declare the Number of instances and the Run mode.
| Run mode | Elapsed time | Effort | Cost |
|---|---|---|---|
| Parallel (all at once) | × 1 — the instances overlap | × n | × n |
| Sequential (one after another) | × n | × n | × n |
Take signing 20 contracts at 20 minutes each: run in parallel, the process only gets 20 minutes longer but burns 400 work minutes; run sequentially, it takes a full 400 minutes on the clock. The same work, two completely different deadline numbers — which is why the run mode has to be declared.
On the diagram, a multi-instance step carries the BPMN marker at the bottom of the shape:
three vertical bars for parallel, three horizontal bars for
sequential, along with ×n.
Boundary events: the exception path
A case under assessment goes past its deadline, the customer withdraws, the system fails — none of that follows the main flow. In BPMN these are boundary events: a double circle sitting on the border of a step. Open the step's Details, set Type to Event, Subtype to Boundary, then pick Attached to step.
In terms of the numbers, this really is a branch leaving the step with probability
p: the p share is taken out first, and only the remaining
1 − p is split among the ordinary branches. Declare “20% past deadline” alongside two
50/50 branches and the result is 20% / 40% / 40%, not 16,7% / 41,7% / 41,7%.
A boundary event with no probability is treated as never happening — the result is identical to what you got before the tool understood boundary events. The tool will prompt you to fill it in; it does not split 50/50 on its own and hand you a made-up number.
If the exception path leaves a parallel block, the tool reads it as an exception that interrupts the whole block: the remaining branches stop too. You will see a warning line saying so explicitly, because this is an assumption about the business, not a self-evident rule.
Interrupting and non-interrupting boundaries
These two are two opposite business meanings, and the tool computes them differently:
- Interrupting — “past deadline, cancel the assessment”. The host step is
cancelled and the case turns off onto the exception branch entirely. The main flow behind it runs
only
1 − ptimes. - Non-interrupting — “past deadline, send a reminder, the assessment keeps running”. The host step finishes normally and the reminder branch runs in parallel. So it adds effort and cost, but does not add elapsed time unless that branch is longer than the host step itself. The main flow behind it still runs a full 1 time.
Appraisal 60 min · reminder 20 min, happens 30% of the time · reply 10 min
Interrupting : 60 + 0,3×20 + 0,7×10 = 73 min (the reply runs only 0,7 times)
Non-interrupting: elapsed 0,7×60 + 0,3×max(60,20) + 10 = 70 min
effort 60 + 0,3×20 + 10 = 76 min
You set it in the step details dialog, the Interrupts the host step field. It is read
from the cancelActivity attribute of the BPMN file and written back out on export.
One case is still an upper bound, and the tool says so rather than staying silent: a non-interrupting branch that rejoins the main flow instead of ending on its own. Along with a boundary event attached to a multi-instance step — there the probability is currently read as applying to the whole step, drawn once per pass, not to each instance.
Timer events and event-based gateways
An intermediate timer event — “wait 3 days”, “after 48 hours” — goes straight into waiting time. The process gets exactly that much longer, but does not burn a single work minute: while the deadline runs down, nobody is sitting and working.
Not just timers: waiting for a message, waiting for a signal and waiting for a condition are all standing around waiting too, so they also go into waiting time. “Wait 2 days for the customer to supply documents” gives the same effort number whichever kind you declare it as.
The one exception is a receive task, which the tool does not convert on its own — it is a step, so you may deliberately want to declare work time on it. The tool only prompts you, and leaves the decision to you.
A timer at the start point is the cycle that triggers the process, and a timer on the border of a step is the threshold that triggers an exception — neither of them is time the case spends inside the process, so neither is added anywhere.
An event-based gateway is where the process stands waiting to see what arrives first: the customer replies, or the deadline passes. In terms of the numbers it is identical to an exclusive gateway — the probability of each branch is the chance that branch “wins”.
The elapsed time of an event-based gateway currently takes the weighted average of the branches, not whichever branch arrives first. For “the customer replies within 10 minutes (70%) or the deadline passes at 3 days (30%)”, the number is 0,7 × 10 + 0,3 × 4320, not 10. If you need the true “whichever arrives first” meaning, declare the duration directly on each branch.
A terminate end event — the kind that cuts off every other running branch — is not yet supported: the tool treats it as an ordinary end point, so the remaining branches are still fully added up. When you load a file containing one, you will see a warning banner saying so explicitly.
OR gateway: opening a subset of the branches
An OR (inclusive) gateway is quite unlike the other two: each branch decides for itself whether it opens, independently of the others. “Technical assessment needed 60%, legal assessment needed 50%” means two separate events — the total need not be 100%, and there are passes where both run.
The tool enumerates every combination that can open. With the two branches above (60 minutes / 100k and 40 minutes / 80k): 30% of passes run only the first branch, 20% only the second, 30% both — which adds up to 55 minutes and 125k. Computing it as an AND gateway (every branch runs) would give 60 minutes and 180k, which is 36% off on time and 80% off on cost.
With 60% and 50%, the chance of “no branch opens” is 20%. BPMN does not allow that (the case would get stuck at the gateway), so that 20% share is redistributed over the remaining combinations. When this share is significant, the tool shows a line saying so.
A branch with no probability declared is treated as always open — exactly how the tool treated OR gateways before, so old processes do not change by a single digit. The tool will prompt you to fill it in, and prompts separately for the case where you filled in some branches and forgot the rest.
An OR gateway with no join cannot be computed by combination: in that case the branches never open together and the opening probabilities get read as split shares (60% and 50% become 54,5% and 45,5%). The tool says exactly what the numbers were changed into — add an OR join gateway and it computes correctly again.
Teams, participants and message flows
Each step can declare a Lane (its role within the process) and a
Participant (a separate organisation — a pool in BPMN). Load a BPMN file and
both are read in from laneSet and participant.
On the diagram, steps in the same lane are laid out in one horizontal band with its name on the left edge — the familiar swimlane drawing.
This is the most valuable metric teams give you: every time a case moves from one team to another, it joins the next person's queue. That is usually the largest source of waiting time, and the place you can cut without anyone having to work faster. The number is computed from the expected number of runs: a rework loop that passes through two teams twice is four handoffs, not two.
A message flow is an exchange between two participants — the case does not travel along it. The tool draws it as a dashed line and does not count the other participant's work in this process's time, cost or number of runs. Treat it as an ordinary flow and every number behind it goes wrong: a 40-minute process gets reported as 70 minutes because it detours through the customer's side.
In the Flows table, the Type column lets you turn a flow into a message flow. A message flow has no probability, so the probability field is locked.
Subprocesses
A step can contain a whole process inside it: “Verify the asset”
is a survey followed by a valuation. Load a BPMN file with a subProcess and the inside
is read in with it; on the diagram it appears as a step with a ⊞ marker
at the bottom, while the metrics table states how many steps it contains.
How it is computed: the tool takes the expected value of the entire inner graph and assigns it to a single step in the parent process — exactly the way it reduces a parallel block. Because of that, an inside with its own gateways, loops or parallel blocks all compute correctly, and a loop or an instance count at the parent level multiplies it naturally: a 40-minute block inside a loop that runs twice is 80 minutes.
Once the step has picked its content (another process, or a diagram embedded in the file), those three fields are locked and only display the numbers taken from inside. If you need extra time or cost for coordinating and managing the whole block, add a step inside that subprocess — there it shows up on the diagram, can be counted and can be edited, instead of hiding in a field on the parent process where nobody sees it.
Those three fields only unlock when the Type is Subprocess and you have not picked any content.
A subprocess has two kinds of content. A link to another process in your account: there is only one copy, so editing that process changes every process using it — badge 🔗. An embedded diagram comes from the file you imported: it is a copy living inside this very process, and editing it elsewhere has no effect — badge ⊞.
Exporting to a file: a linked step is written in the standard
callActivity notation, and the called process travels along inside the same file —
open it in Camunda or Bizagi and it is all there, import it back here and it reconnects to the
original process instead of spawning a copy. The numbers are written alongside as a
safety net: if the file ends up in another tool, that tool still reads the right numbers.
Whoever receives the file cannot read the linked process (it belongs to your account), so for them the step is just the four captured numbers — with the capture date, and past 30 days the tool says plainly that the numbers are stale rather than silently carrying on with them.
An embedded diagram imported from a file cannot be edited from the Steps table — that table only builds rows for the steps at the outermost level. The “Split into a separate process” button in the step Details dialog turns its inside into an ordinary process in the list, and the parent step switches to a link to that process. The totals of the current process do not change by a single number; in exchange, from then on you can edit it, version it, and share it across several processes.
The page of a process that is in use has a “Used by” block listing the processes that call it, along with the multiplier: if the caller wraps the link in a step with 20 sequential instances, then adding 5 minutes here raises that side by 100 minutes. For the same reason, deleting a process that is in use is blocked — the tool lists who depends on it before you decide.
If the linked process is deleted, the tool does not compute it as 0 but uses the captured figures from the most recent save, with a red line stating the capture date. A snapshot older than 30 days is dropped — a week-old number is an estimate, a half-year-old number is fiction. Cycles (A calls B, B calls A back) are blocked at the moment you pick them.
An empty subprocess (whose inside could not be loaded) or one whose expected value cannot be computed (an inside that loops forever, or has no start point) has the whole block computed as 0, and the tool says so on screen instead of staying quiet. Every warning about the structure inside — orphan steps, gateways missing probabilities — also shows up with the name of the block containing it.
Nesting goes at most 5 levels deep. Deeper than that, the innermost part is cut off, and you are told it was cut.
What happens if you leave things blank
Leave the waiting field empty and it is 0, the instance count defaults to 1, no boundary event means no exception branch, and every number is exactly what it was before these features existed — old processes do not change by a single digit. Lanes and participants are only labels — they change no number at all, they only add the “handoffs” metric.