Workflow automation pricing is one of those things that looks simple until your bill arrives. You sign up for a plan, connect a few tools, build your first workflow — and then two months later you're trying to figure out why you're paying three times what you expected.

The confusion almost always comes down to one thing: whether the tool charges per task or per execution. They sound similar. They're not.

The per-task model: how it actually works

Most automation platforms — Zapier and Make are the most common examples — charge based on tasks or operations. A task is a single action performed by a single step in a workflow.

So a 5-step workflow that processes one record = 5 tasks. Run that workflow on 1,000 records and you've consumed 5,000 tasks.

This feels reasonable at low volume. If you're running a few hundred automations a month, it doesn't matter much. The problem comes when you start building real operational workflows.

Consider a fairly standard lead enrichment workflow:

1. Trigger: new contact in HubSpot

2. Look up company data from Apollo

3. Check if domain already exists in HubSpot

4. Validate the email with Hunter

5. Score the lead based on 5 firmographic criteria

6. Update HubSpot with enriched fields

7. Add to outbound sequence in Instantly if score is high enough

That's 7 steps. If 500 new contacts hit your CRM in a month, you've just consumed 3,500 tasks. From a single workflow.

Add a few more workflows to keep your CRM clean, re-score existing contacts, and handle inbound from different sources — and you're burning through thousands of tasks a day.

The math nobody warns you about

Here's a worked example using Make's pricing as a reference (numbers approximate; always check current pricing):

• Core plan: roughly 10,000 operations/month

• Pro plan: roughly 40,000 operations/month

A GTM team running three active workflows:

• Lead enrichment: 7 steps, 300 new contacts/month = 2,100 operations

• Nightly CRM re-score: 5 steps, 2,000 records/run, 20 runs/month = 200,000 operations

• Inbound lead routing: 4 steps, 150 records/month = 600 operations

Total: 202,700 operations per month. That's not a heavy setup. That's a small RevOps team doing the basics.

On per-operation pricing, you'd need to be on an enterprise plan for a workflow stack like this. On per-execution pricing, the same setup costs a fraction.

The per-execution model: a different way to count

Per-execution pricing works differently. One execution = one full run through a workflow, from trigger to final destination. It doesn't matter how many steps are inside.

The same 7-step lead enrichment workflow from above? Each contact that runs through it counts as 1 execution. 300 contacts = 300 executions. Not 2,100.

The nightly re-score? Each time the workflow runs = 1 execution. 20 runs/month = 20 executions. Not 200,000.

This is how n8n and Datamorf price their products. The philosophy is the same: you should be able to build complex, multi-step workflows without being financially penalized for the complexity.

You should never be penalized for building complex workflows.

At low volume and low complexity, the two models are roughly comparable. At scale and complexity, per-execution pricing becomes significantly cheaper and more predictable.

Why predictability matters more than the headline price

When you're evaluating automation tools, the headline price is almost meaningless. What matters is whether you can predict your cost as your usage grows.

Per-task pricing makes this hard because:

• Adding a step to an existing workflow increases costs immediately across all future runs

• Increasing data volume multiplies costs in a non-linear way when you have multiple workflows

• Improving your automation (adding enrichment sources, more validation steps) costs more, not less

Per-execution pricing gives you a cleaner model:

• Adding steps to a workflow doesn't change the cost

• You pay for volume of records processed, not complexity

• Improving your workflows (more steps, better logic) has no pricing penalty

For RevOps teams managing a large CRM and running automated processes at scale, this difference in predictability matters as much as the absolute price.

How to estimate your actual monthly cost

Before picking a tool, run this calculation:

1. List every workflow you plan to build

2. Estimate the number of records processed per workflow per month

3. Count the steps in each workflow

For per-task tools: multiply steps x records for each workflow, sum across all workflows. That's your monthly task count.

For per-execution tools: just count total records processed across all workflows. Steps don't factor in.

The gap between these two numbers is what tells you which pricing model fits your actual usage pattern.

If you're building simple, 2-3 step workflows processing a few hundred records a month, per-task pricing is probably fine. If you're building multi-step operational workflows that run against thousands of records, per-execution pricing is meaningfully cheaper and easier to budget.

What to look for beyond pricing

Pricing model matters, but it's not the only variable. A few other things worth checking:

• Execution limits vs. task limits: some tools cap the number of workflow runs (executions) independently of tasks. Read the fine print.

• Data volume caps: some platforms throttle or charge extra for high-volume record processing regardless of the pricing model

• Overage behavior: does the tool pause workflows when you hit your limit, or keep running and charge overages? One is recoverable; the other is a surprise bill.

• Active workflows vs. total workflows: some plans limit how many workflows can be active simultaneously, not just how many you can create

The cleanest setups are ones where the pricing model maps to something you actually control. Per-execution pricing, where you're essentially paying for data volume processed, is the most intuitive model for teams that think in terms of records and workflows rather than individual step-by-step task counts.

A note on Datamorf's pricing model

Datamorf uses per-execution pricing. One execution covers the full run through a workflow: trigger, data sources, transformations, destinations. A 10-step waterfall enrichment counts as 1 execution.

For GTM teams building multi-step data activation workflows, this makes costs predictable as usage scales — which is the main reason execution-based pricing exists.

If you're evaluating automation tools for your GTM stack, datamorf.io has more on how per-execution pricing works in practice.