I agree that checking the "task instances" report is the definitive step. The nuance is that some platforms count a *reassigned* task as a new instance. So if your sequential approval has a task that gets reassigned from a departing employee to a new hire, you might see two billed tasks for what was logically one approval step.
This is why your trial run should include not just the happy path, but a common error state like a reassignment or an escalation. The count difference can be substantial.
Your bill is too high.
Absolutely, that reassignment multiplier is so real. We saw it on a compliance audit where tasks bounced between delegates - each bounce counted as a new "instance" on the report. The vendor's logic was "new assignee, new task."
One extra caveat: some platforms also trigger a fresh task if the *due date* is extended, even if the assignee stays the same. So if you push a deadline, check if that ticks the counter.
Prompt engineering is the new debugging
Think of an activity as the overall workflow or project, and tasks as the individual work items assigned to someone (or some system) within it.
For vendor onboarding, the "activity" is "Onboard Vendor X". The tasks are the steps to complete it: "Complete initial risk assessment", "Approve contract", "Collect insurance certificate".
The cost surprise comes from multipliers. If that contract needs three sequential approvals, that's three tasks. If it gets reassigned or the due date is extended, that might count as another task depending on the platform's billing logic.
Check the platform's audit logs for "task instances" during your trial, and run a scenario with a reassignment to see the real count.
Build once, deploy everywhere
All these theoretical explanations are nice, but you'll get burned by the vendor's specific implementation. You need to run a test.
Create a dummy vendor onboarding workflow with a single approval step assigned to a group of three people. Execute it. Then pull the platform's usage report. I guarantee the number of "tasks" recorded will be either 1 or 3, and that's your real answer.
The pricing page definitions are marketing. The report is your bill.
-- bb
Completely agree that the report is what matters. The tricky part is that some platforms separate "task definitions" from "runtime instances" in their analytics.
You could run your test and see 1 task in the workflow designer's log but 3 in the consumption billing report, because the latter counts every execution token. That's the real gotcha - you have to know which report your invoice is based on.
Our team got burned by assuming the designer view was authoritative. Now our test checklist includes running the process and immediately checking the billing API endpoint or the vendor's "usage" dashboard, not the activity audit log.
Ship fast, measure faster.
This is a critical distinction, and it's often buried in the API docs. The "task definition" is a static, configured object, like a step in a template. The "runtime instance" is the discrete unit of work created from it each time the engine needs to assign something, which is what gets metered.
We had a similar experience: the orchestration logs showed a clean "task completed" event, but the underlying engine's internal queue was generating two "work items" - one for the assignment and another for the completion callback. Both were counted as billable instances. You have to trace the actual execution tokens, not the business events.
Exactly. The "discrete unit of work" definition is the only one that matters. And vendors will split hairs to create more units.
The worst offender I've seen is escalations counted as a completely new task, even though it's the same work item sent to the same person but via a different alert path. It's a pure meter spin.
show me the logs
That escalation example is spot on. We saw something similar with a conditional approval path that created a separate "priority" task, billed as new, even though it was the same human action on the same form. The only difference was a flag in the database.
It all comes down to tracking the engine's "create" events, not the logical steps.
Docs save time
You've hit on the core budgeting problem perfectly - thinking in terms of the diagram versus the atomic billable unit. That diagram-to-invoice gap catches so many teams off guard in early planning.
When I coach teams through this, I ask them to look for the "forklift events" in their workflow. For instance, if you have a single "Collect Documents" activity that generates requests to five different departments, that's one box on your flowchart but five discrete assignments in the engine, with all their attendant reassignments and escalations. The multiplier isn't a bug, it's the natural consequence of translating a logical step into physical work distribution.
So your trial advice is spot on. The only thing I'd add is to make that dummy test as *boring* and *typical* as possible. Model the exact mundane process you already have, like a simple three-person invoice approval. The real surprise won't be in the exotic scenarios, but in how the platform interprets your most basic, day-to-day sequence.
Architect first, buy later
The schema request is a powerful tactic, but I've found its usefulness depends entirely on who provides it and the vendor's architecture. An open platform with an API-first design will likely hand it over readily. A more monolithic, managed service will treat their data model as a core secret.
Even if you get a schema, the presence of a `parent_activity_id` doesn't guarantee transparency if the billing logic is a separate, proprietary service reading from an internal event stream. The tables you can query might be a curated subset. The true test is whether the usage report you're billed on can be perfectly reconstructed from the queryable data they've exposed. In my experience, that's rarely the case by default.
Let's keep it constructive
Everyone's giving you flowery analogies but ignoring the hard cost. Let's cut through it.
The pricing page is useless for forecasting because vendors define tasks at the engine level, not the diagram level. In your vendor onboarding example, that "Approve contract" step could be a single task, or it could spawn three separate billable units for each approver, plus another if it gets reassigned.
The only explanation that matters is in your trial's usage report after you run a workflow. Build your dummy process, execute it, and check what the meter actually counted. That's your real definition.
-- bb
The pricing page definitions are useless for planning. You need to check what they actually bill.
For your vendor onboarding, the step "review supplier questionnaire" is one activity on your diagram. But if it sends a form to three people, the engine likely creates three separate billable tasks.
You have to run a test and check the usage report. That's your real answer.
You're right to question the audit. If you can't reconstruct the bill from your own logs, you're flying blind.
I've forced vendors to do this: run a controlled test for exactly 100 logical steps, get the usage report, and then demand they map each line item back to a traceable log entry in my system. Half the time they can't, and the discrepancy becomes a permanent discount on the rate card because they can't prove their meter.
If they won't provide the schema or the raw event feed, assume the multiplier is arbitrary. Your negotiation starts there.
pay for what you use, not what you reserve
That controlled test is a brilliant forcing function. I've seen it work, but it relies on the vendor having a coherent traceability system themselves, which isn't a given.
A cautionary tale: we once did this, and the vendor's support team couldn't map the charges. It turned out their billing system was a separate legacy module that polled aggregated stats, not actual events. The disconnect wasn't malice, just technical debt. We still got the discount, but it was because their own right hand didn't know what the left was doing.
So while the tactic works, the reason it works can be revealing in a different, slightly worrying way.
That's the key, isn't it? "The pricing page definitions are marketing. The report is your bill." The real learning is in the gap between the two.
Your 1 vs 3 outcome is a perfect example of that ambiguous line. In some systems, that group assignment might create a single task with three participants. In others, it spins up three unique work items. You can't even rely on the UI showing you three distinct items to know which way they bill it.
The only other step I'd add to your test is to trigger an escalation or reassignment on one of those three tasks and see if that generates a new, billable "event." That's where the real meter-spinning tends to hide.