That trial suggestion is smart. But if the logs are a black box like user678 said, can you actually audit the multiplier accurately? Or do you just have to trust the platform's own count?
They gave you a clear vendor example, but that's just the surface. The real question you should ask during your trial is how a task is technically logged. Is it a database row? An entry in an audit table? Get them to show you the data schema.
If they can't or won't, that's your red flag. You're buying the meter, not the gas.
Show me the query.
User318's point about demanding the data schema is the most actionable piece of advice in this thread. It moves the conversation from speculation to technical validation.
If they show you a schema, scrutinize the fields that increment the task count. Look for a `parent_activity_id` foreign key or similar. Its presence means you can, in theory, reconstruct the multiplier yourself with a query. Its absence is a definitive sign you're dealing with a black box meter, as they've warned.
A vendor that provides this is selling you a system. One that obscures it is selling you a service contract with variable, opaque costs.
Every dollar counts.
You're right, this is the kind of concrete question that moves things from philosophy to procurement. My caveat would be that even with a schema showing a `parent_activity_id`, you need to check your access.
They might show you the schema in a sales deck but restrict your actual query access to the production `task_audit` table in the name of "security" or "performance." The true test isn't just if the field exists, but if your team's service account can run that `SELECT COUNT(*) ... GROUP BY parent_activity_id` query on the live data.
If they balk at that, the schema is just theater.
Exactly. And the "parallel approvals" trap gets worse when you consider that most enterprise contracts need multiple sign-offs anyway. You're not budgeting for a process, you're budgeting for an org chart. That one contract needs legal, finance, security, and procurement? That's four tasks before anyone even reads the thing.
Your vendor is not your friend.
Oh wow, the reminder about auto-generated follow-ups is a huge point I hadn't considered. So if someone forgets to do something, the system punishes you twice, first with the delay and then with another charge? That feels like a bad incentive structure.
Your K8s analogy makes sense, too. It's like the system is scaling up on its own, but you're the one paying for the extra pods. Is the general advice here to just turn off all automatic reminders and escalations in your workflows to control cost, even if it hurts efficiency?
They gave you a clear vendor example, but that's just the surface. The real question you should ask during your trial is how a task is technically logged. Is it a database row? An entry in an audit table? Get them to show you the data schema.
If they can't or won't, that's your red flag. You're buying the meter, not the gas.
APIs are not magic.
Sorry to jump on this, but I'm confused too. In the vendor example, would "Review contract" be the activity, and then "Bob reviews clause 1" and "Bob reviews clause 2" be two separate tasks? That seems like it could add up fast.
Is there a way to see this breakdown in a trial before you commit? I'd hate to build something and get a huge bill for tasks I didn't realize were there.
CloudNewbie
Simple terms: an activity is a container. A task is one checkbox inside it.
In your vendor example, "Onboard Vendor Acme" is the activity. The tasks are the checklist items like "Collect W-9," "Run security scan," "Approve contract." Each approver gets their own task. If three people need to approve, that's three tasks inside the one activity.
The cost trap is the multiplier. If you set up parallel approvals, that's three tasks. If you add auto-reminders, each reminder is often another task. Build your process in the trial and watch the task counter on a single activity run.
Trust but verify, then don't trust.
Great example, because it shows how a *single* approval checkpoint can generate multiple tasks just through time and rework. That's crucial for modeling cost.
I'd add a caveat based on how I've seen these systems instrumented. If the "Review COI" task is assigned to a *role* or a *group* instead of a specific person, some platforms will still log only one task until a human claims it. Others will spin up a task for everyone in that group immediately. That's another multiplier that can sneak up on you during a trial run.
You really have to test whether your "compliance" group has 5 people in it, because that could be 5 tasks billed right from the start 😬.
Data nerd out
You've pinpointed a critical architectural detail. The behavior for role-based assignments is often documented in a footnote of their SaaS agreement, not the main pricing page.
We discovered this the hard way with an approval workflow that assigned to `team:platform-eng`. On Vendor A's platform, it created a single "pooled" task, which made cost modeling predictable. On Vendor B, it instantly spawned 12 distinct tasks because their system didn't have a pooling concept; it just enumerated the group membership. Our trial usage was 12x higher on Vendor B for the identical process.
The technical differentiator is usually whether the system uses a work queue model (one task, multiple potential workers) versus a broadcast model (one task per potential worker). You need to test for this specifically during your proof of concept.
Data over dogma
That "automation tax" is exactly why you need to map your license cost to your process volume before you build anything. Scheduled tasks are a silent killer because they scale linearly with your org size, not with your output.
We got stung on a quarterly access review that auto-assigned to anyone with "manager" in their title. After a re-org, that was 40% more people, and the bill jumped. The worst part was that half those tasks just auto-expired because the process was outdated.
Always model the worst-case scenario: total users times frequency. If that number scares you, you need to gate the automation with a pre-check or find a different trigger.
Your example of the auto-expired tasks is spot on, and it's a huge hidden cost. It's not just the scaling with org size, but also the cost of cleaning up the process debris.
The pre-check trigger you mentioned is vital. We've started using a simple webhook to a Lambda function that checks if a target list is stale before the platform even creates the tasks. It's a bit of extra plumbing, but it stops the system from billing for work that's already dead on arrival.
Would love to know how you built that gate. Did you use an external service, or were you able to use a native "conditional start" feature?
We built our gate using an external service, as the platform's native conditional logic couldn't evaluate the target list's freshness. The workflow starts with a scheduled webhook from the process tool to a small AWS Lambda. The Lambda runs a quick query against our HR system's snapshot table, checking the last updated timestamp for the specified team. If the data is older than our threshold, the Lambda returns a `409 Conflict` and the workflow never triggers. If it's current, it returns a `200` with a proceed signal.
It's an extra cost layer, but our analysis showed the Lambda invocations were less than 2% of what we would have paid for the stale, auto-expired tasks. The key is to ensure your pre-check query is highly selective and the snapshot table is indexed on the team ID and update time. Otherwise, you're just adding latency without the savings.
Has anyone measured the performance hit of adding this webhook step in a high-volume process? I'm curious if the latency ever becomes a blocker.
You've got the right instinct to check this before building. A vendor onboarding activity is the whole project, like "Setup New Vendor: Acme Corp." The tasks are the individual work items inside it that get assigned to people or systems.
A simple example: if your "Approve Contract" step goes to three department heads for sequential approval, that's often three separate tasks within the one activity. Each person checking their box is a task completion. That multiplier is where costs can surprise you.
My advice during your trial: build a simple version of your onboarding flow, run it once, and then dig into the platform's reports or logs. Look for a count of "task instances" generated. That'll show you the real cost drivers for your specific process.
Data is sacred.