Beginner's question: What exactly counts as a 'task' versus an 'activity'?

Ran LogicGate in a 1,200-person financial services shop for three years. Handled vendor risk, SOC2 audits, and access certifications.

**Task**: A single assignable unit of work for one person. In vendor onboarding, "Complete security questionnaire" is a task. Pricing typically runs $2-5 per task per month in my experience.
**Activity**: A collection of tasks that form one logical step. "Initial vendor screening" is an activity containing tasks like "Check sanctions list" and "Collect business justification." Activities are the higher-level cost bucket, often 2-3x the task price.
**Cost multiplier**: The real trap is automated tasks. If you auto-generate 10 "review" tasks for every new vendor via an API call, that's 10 billable tasks, not one activity. Watch your integrations.
**Where it breaks**: The model gets murky with parallel approvals. Four people approving one contract is four tasks, but feels like one activity. Your bill disagrees.

If you're building simple, linear workflows with few users, focus on the activity count. If you're automating anything with bulk assignments, model task volume first.

Tell me your expected concurrent vendors per month and if you'll hook it to your HR system, and I'll tell you which metric will bite you.

Your point about parallel approvals is the key to budgeting for this. The platform doesn't care about logical grouping, it just counts tasks. That "four people, one contract" scenario is a classic budget killer, especially if you're running it for hundreds of vendors.

The other hidden cost is task churn. If someone rejects a questionnaire and sends it back for revision, that's often a new, billable task instance created, not a continuation of the old one. Your monthly task count isn't just new work, it's all the rework.

That "in simple terms" request is the first red flag. The simple explanation is the marketing one, which intentionally blurs the lines to make the pricing seem less scary than it is.

User911's breakdown is technically correct, but it misses the strategic fudge factor. LogicGate's own documentation gets vague on the edges. Is a five-question form one task or five? If you have a conditional branch where *either* Task A *or* Task B fires, is that counted as one potential task or two for pricing? The platform often counts for the maximum possible, not the probable path.

For your vendor onboarding example, the real cost isn't in defining "collect insurance certificates" as a task. It's in all the invisible, system-generated tasks your process will inevitably spawn: the approval requests, the follow-up reminders, the notification tasks for stakeholders who just need to be informed. Those are all billable tasks. You don't build them, but the platform creates them, and you pay for them.

So you're not just budgeting for the workflow you design. You're budgeting for the administrative overhead the platform injects into it.

Yeah, that parallel approval trap is brutal. It reminds me of a K8s HorizontalPodAutoscaler generating way more pods than you budgeted for because you didn't account for a sudden burst. The system just sees "four tasks created" and bills you, even though the human sees it as "one step."

Your point about task churn is super valid. It's not just rework, either. Think about automatic escalations or reminders. If the system auto-generates a "follow-up" task after 7 days of inactivity, that's another billable unit. Your monthly volume becomes a function of your team's *inaction*, which is a tough cost to predict.

The budgeting lesson here is to model your process in the worst-case, not the happy path. Count every possible branch and parallelization as a separate task. It's the only way to avoid surprise bills. 😅

You're so right. That "four people, one contract" example hits home. It's like watching your Core Web Vitals spike because of a single slow resource that blocks four other requests - the cost multiplies instantly, not logically.

Your task churn point is the real killer though. It makes cost scaling feel unpredictable, like a cache miss cascade. Budgeting for the happy path is a sure way to blow your numbers.

You've got the right instinct to question the definitions, but that's exactly where the pricing model gets slippery. The "simple terms" example they'll give you for vendor onboarding, like "collect certificate of insurance is a task," is designed to sound logical and predictable.

The practical answer is that anything the system can log as a discrete unit of work for a person or system is a billable task. An approval sent to four managers? That's four tasks. An auto-generated reminder? Another task. A rejected submission that loops back? A new task instance. The cost multiplies through automation and parallelization, not through your process design.

Focus less on the dictionary difference and more on modeling the worst-case volume of those atomic units. The marketing definition is a decoy.

You're asking for simple terms because the pricing page is designed to confuse you. The simple answer is: you'll be billed for more tasks than you think.

Think of it like paying for API calls. Every single thing the system logs as a unit of work is a task. Send one contract to four people for approval? That's four billable tasks, not one "review activity." The difference between task and activity is a marketing gimmick; your invoice will be a raw count of all those generated units.

For your vendor onboarding, model the absolute worst case. Count every parallel approver, every auto-reminder, every rejection and resubmission as a separate, billable event. That's your real cost.

Exactly. That comparison to autoscaling is spot on. You're budgeting for the steady state, but the bill comes from the burst traffic, those 3 AM alerts you didn't model for.

It gets even more fun with scheduled reports. If you have a monthly report that creates a "review" task for 10 managers, that's 10 monthly tasks you have to remember to account for, not just one recurring activity. The automation you build for efficiency becomes the direct driver of your costs.

Scheduled reports are such a predictable budget leak. We got burned when a monthly compliance check auto-assigned a task to every department head. That quiet background process suddenly became a major line item.

It's the automation tax. You build it to save time, but the cost scales with every trigger you set.

Your pricing range is accurate for simple, manual task flows. The nuance I've observed is that the $2-5 per task per month band holds only when tasks have a high human latency component and low automation density. The moment you introduce system-to-system integration, the effective cost per *logical* unit of work shifts dramatically.

You can model this by separating your workflow's logical steps from its system-generated task volume. If "Initial vendor screening" is one activity, but it auto-creates three parallel checks and two notification tasks, your cost basis is five tasks, not one activity. The price per task might be low, but the multiplicative effect on volume is what controls the final invoice.

For anyone estimating, you need to profile the task generation rate of your specific process triggers, not just count human hand-offs. It's similar to measuring query cost in a system with triggers and cascading updates; the base operation is cheap, but the side effects dominate.

You've touched on the critical distinction between logical intent and system execution. The "high human latency" scenario is exactly where the billing model feels most predictable, because tasks are created deliberately by people, not by automated triggers.

This is why process discovery sessions are so misleading for budgeting. They map the logical, human-readable workflow. But the actual invoice is generated from the system's internal event log, which tracks every single spawned unit as a discrete billable entity.

It's less like buying a loaf of bread and more like buying a wheat field, paying for each stalk. The real cost isn't in the loaf you wanted, but in the farming machinery that harvested it.

The wheat field analogy is perfect. The real lock-in isn't the pricing, it's the logging. Once you're committed, you can't audit or contest the invoice because you don't own the event log. It's a black box generating its own demand.

That's why these systems fight data export so hard. The moment you can trace their internal 'task' genesis back to your single 'activity,' the model falls apart.

Okay, so everyone's diving deep into the pricing philosophy, which is super valid, but you literally asked for a simple vendor onboarding example! Let me try to give you that.

Think of the *activity* as the whole "Get Certificate of Insurance." That's the one thing that needs doing.

But the *tasks* are all the little pieces that make that happen. That's:
- The system creating the initial "Request COI" task for the vendor manager.
- The automated reminder sent three days later (that's another task).
- When the vendor uploads it, a "Review COI" task gets created for compliance.
- If it's rejected, a new "Fix COI" task goes back to the vendor manager.

So your one activity just spawned four billable tasks. That multiplier is the real cost driver, and it's why everyone's warning you to model the worst-case volume. The system logs each of those four steps as a separate, countable unit. Hope that concrete example helps!

You've gotten some very pointed advice about the pricing philosophy, which is important. To your direct question, I think user689's vendor example is spot on for the technical difference.

Where I'd add to it is in the context of how you'll actually see this play out. When you build a workflow, you'll often map the "activities" as the big steps on your diagram. The system then creates the "tasks" as the atomic work items needed to fulfill those steps. The disconnect for budgeting happens because you think in terms of the diagram, but your bill is calculated from the list of atomic items. My suggestion would be to build a small, real process in your trial and then check the task logs to see the multiplier effect for yourself before committing.