Automation Glossary: The Terms in Every Proposal, Defined

You get an automation proposal, or you open the pricing page of a tool a colleague swears by, and half of it is in a language nobody taught you. It says the workflow is "webhook-triggered," bills in "tasks" or "operations," needs "idempotent retries," and routes edge cases to a "human in the loop." You run the operation, not a platform team, so you nod, sign, and quietly hope none of those words hide a cost or a failure mode you should have caught.

The jargon is not there to confuse you. Each term names a real thing that decides whether an automation is cheap or expensive, reliable or brittle, worth building or better left as a manual step. Once you can read the words, you can read the proposal, and you can tell a solid plan from a hopeful one.

This is a reference. Skim it, or jump to the section that matches whatever confused you last. Each term gets a plain definition, then the thing it actually costs you or saves you on a real build. Where a word points to a deeper topic we have written up, the link is there. Where a vendor defines a billing unit in its own docs, that is the source we use, because a task on Zapier and an operation on Make are not the same size, and the difference is money.

The words that describe the work itself

Start with the vocabulary for the automation as a whole, before any of the plumbing underneath it.

Workflow automation is software doing a repeatable, rules-based sequence of steps that a person used to do by hand. A lead comes in, it lands in the CRM, finance gets pinged, the spreadsheet updates. No one re-keys anything. If you want the full picture of the category and the tools in it, we cover that in workflow automation tools.

Business process automation (BPA) is the same idea zoomed out to a whole process rather than one handoff. Not "sync this form to that CRM," but "run the entire order-to-cash process end to end." BPA is workflow automation plus the approvals, exceptions, and reporting around it.

Trigger is the event that starts a workflow. A new form submission, a closed deal, a Stripe charge, a file dropped in a folder, a scheduled time. Everything downstream fires because the trigger fired.

Action is a step the workflow performs after the trigger: create a record, send a message, update a field, call another system. A workflow is one trigger and one or more actions.

Run (or execution) is one full pass of the workflow, from trigger to final action. When people ask "how many runs a month," they mean how many times the whole thing fires. This number, times the steps inside each run, is usually what drives your bill.

No-code and low-code describe how the automation gets built. No-code means visual, drag-and-connect, no programming. Low-code means mostly visual with a bit of scripting for the hard parts. Both are real, both have ceilings, and we lay out where those ceilings are in our guide to no-code automation platforms.

Robotic process automation (RPA) is a bot that mimics a human clicking through a screen: it moves the mouse, types into fields, copies from one app and pastes into another. RPA is what you reach for when a system has no API and screen-scraping is the only door in. We go deeper in what is robotic process automation.

How systems actually talk to each other

Most of an automation's real work is getting two tools that were never designed to cooperate to exchange data cleanly. This is the plumbing vocabulary.

API (application programming interface) is the official set of doors a piece of software exposes so other software can read and write its data. When a workflow "uses the HubSpot API," it means it talks to HubSpot through those sanctioned doors instead of scraping the screen. APIs are the difference between an integration that holds and one that breaks the next time a button moves.

Endpoint is one specific door in an API: a single URL you call to do one thing, like "create a contact" or "list invoices." An API is the building, endpoints are the individual doors.

Webhook is a message a system pushes to you the instant something happens. You register a URL, and when the event fires, the source sends an HTTP request straight to that URL. It is a push model, near real time, and it does not waste a call when nothing has changed.

Polling is the opposite pattern: your workflow asks the source "anything new?" on a fixed schedule, say every 15 minutes, and compares the answer to last time. It is a pull model. Polling is simpler to set up but adds latency and burns calls checking when nothing happened. As a rule, we prefer a webhook when the source offers one and fall back to polling when it does not.

Payload is the actual data carried in a webhook or API response, almost always as JSON, a structured text format of keys and values that both machines and humans can read. When a build "parses the payload," it is pulling the fields it needs out of that JSON.

Authentication is how a workflow proves it is allowed to touch your data. Two common forms: an API key, a long secret string you paste in once, and OAuth, a token-based login flow where you grant access by clicking "allow" instead of handing over a password. OAuth is safer because access can be scoped and revoked without changing a shared secret.

Rate limit is the cap a vendor puts on how many API requests you can make in a set window. Go over it and the API rejects the extra calls, usually with an HTTP 429 Too Many Requests response. Rate limits are why a job that syncs 5,000 records cannot just fire 5,000 calls at once. It has to pace itself, and a build that ignores this silently drops data.

iPaaS (integration platform as a service) is a cloud platform whose whole job is connecting your apps: prebuilt connectors, data mapping, scheduling, retries, and monitoring in one place. Per AWS and IBM, it is the managed layer that orchestrates the integrations rather than you wiring each one from scratch. Zapier and Make sit in this category.

The words on your bill

Here is where vocabulary turns directly into cost. Two tools can run the identical workflow and charge you wildly different amounts, because they count different things.

Task (Zapier). A task is "any successful action that runs in Zapier," per Zapier's own usage docs. Triggers do not count. Failed actions do not count, because Zapier only bills successful ones. But every successful action step does, including steps inside an error path and steps replayed in a full Zap replay. A three-action workflow that runs 1,000 times a month is roughly 3,000 tasks, not 1,000.

Operation (Make). An operation is a single module run, per Make's documentation. The first module in a scenario always costs one operation even if it returns nothing, and modules that process multiple bundles of data can burn several operations in a single run. Make now bills in "credits", with existing operations converted at a 1:1 ratio for standard non-AI usage, so the counting model still tracks module runs even though the unit changed names.

The practical takeaway: Zapier counts per successful action, Make counts per module run. Neither one bills you per workflow. This is why a workflow that looks cheap in a demo gets expensive at volume, and why "how many steps, times how many runs" is the first math to do before you commit to a platform. We work the full numbers in the cost to automate a process.

Seat is a per-user charge layered on top of usage. Some platforms bill both, so read whether a plan is priced per task or per seat or both before you scale the team on it.

The words that decide whether it survives volume

An automation that works in a demo and an automation that runs unattended at 5,000 records a month are different animals. These terms name the gap.

Idempotency is the property that running the same operation twice has the same result as running it once. Charge a card with an idempotency key, a unique token attached to the request, and if a network hiccup makes the workflow retry, the system recognizes the repeat and does not charge twice. Without idempotency, every retry risks a duplicate invoice, a double Slack post, a contact created twice. It is the single most common thing missing from a DIY automation that "worked until it didn't."

Retry is what a workflow does when a step fails for a temporary reason, like a rate limit or a brief outage: it waits and tries again. Good retry logic backs off and gives up after a sensible number of attempts. Bad or missing retry logic drops the record on the first hiccup and no one notices.

Error handling is the plan for when a step fails for a real reason, not a temporary one: a required field is empty, an address won't validate, an API returns garbage. Does the workflow stop, skip, route the record to a human, or log it for review? A build without an error path silently loses data, and silent data loss is the most expensive kind.

Race condition is what happens when two runs touch the same record at the same time and step on each other. Two forms submitted a second apart both create the "same" new customer, and now you have duplicates. Handling this is unglamorous and it is exactly the work that separates a durable build from a fragile one.

Deduplication (dedupe) is catching those duplicates before they land, usually by matching on a stable key like an email or an external ID. Backfill is the one-time job of loading historical records into a new automation so it starts with your existing data, not just what arrives after go-live.

Monitoring is knowing when a workflow breaks without a customer telling you first. Alerts on failures, a log you can actually read, a dashboard for volume and errors. An unmonitored automation is a liability the day it fails quietly, and they all fail eventually.

The AI layer, without the hype

The newest and haziest vocabulary. AI adds real capability to automation, and it adds new ways to burn money and trust if you do not know what the words mean.

Large language model (LLM) is the AI that reads and writes text: the class of model behind ChatGPT, Claude, and Gemini. In an automation it does the fuzzy jobs rules cannot, like reading a messy email and pulling out the order details.

Token is the unit an LLM reads and writes. A token is a word, part of a word, or a piece of punctuation, and you are billed per token in and per token out. Context window is the maximum number of tokens a model can hold at once, prompt and answer together. Feed it more than fits and the earliest content falls out of view.

Prompt is the instruction you give the model. Half of getting reliable output from an LLM is a precise, well-constrained prompt, which is craft, not luck.

Retrieval-augmented generation (RAG) is the pattern where the system first fetches the relevant facts from your own data, then hands them to the model to answer from, instead of trusting the model's memory. RAG is how you get an AI that answers from your actual knowledge base rather than making things up.

Hallucination is the model stating something false with total confidence. It is not a bug you patch, it is a property you design around, with retrieval, validation, and a human check on anything that matters.

Extraction is using an LLM to pull structured fields out of unstructured input: line items from a PDF invoice, an address from a signature block, a ticket category from a paragraph of complaint. It is one of the highest-value AI jobs in an ops stack, and we cover it in PDF data extraction.

AI agent is an LLM given tools and a goal, so it can take steps on its own: look something up, call an API, decide what to do next, and loop until the task is done. Agentic AI is the broader term for systems built around that autonomy. The two get used interchangeably and they are not identical, which we untangle in agentic AI vs AI agent and what is agentic AI.

Human in the loop is the deliberate checkpoint where a person approves or corrects the AI before it acts. For anything that spends money, contacts a customer, or is hard to undo, a human in the loop is the difference between a confident automation and a reckless one.

How these words show up on a real build

Here is the same vocabulary in a single sentence from an actual project: "A new deal in HubSpot fires a webhook, the workflow extracts the billing details, creates a Stripe invoice with an idempotency key so a retry never double-charges, dedupes against existing customers, posts the link to Slack, and routes any deal over $10K to a person for approval."

Every term in that sentence is doing load-bearing work. Miss the idempotency key and finance chases phantom charges. Skip the dedupe and the CRM fills with duplicate customers. Drop the monitoring and the first anyone hears of a break is an angry client. This is why the words matter more than the demo.

This is also the work we do at bottta. We are an automation studio, so we design the workflow, wire the integrations, handle the idempotency and error paths and monitoring that never make it into a screenshot, and stay on to fix what real volume shakes loose. Two ways to work with us: a $3K per month retainer when you have a rolling list of automations and want a team owning up to three active workflows at a time with ongoing monitoring and fixes, or a $4K fixed project when you have one clearly scoped build, integrations included, with 30 days of post-launch support. If you would rather run the tools yourself, Zapier, Make, and n8n are all real options for simple, low-volume workflows, and we compare them honestly in n8n vs Zapier vs Make. The line we would draw: DIY holds for a two-step handoff at low volume. The moment idempotency, dedupe, and error handling enter the picture, the maintenance eats the savings, and that is where a studio build pays for itself.

Frequently asked questions

What is the difference between a task and an operation?

A task is Zapier's billing unit and equals one successful action step, per Zapier's docs. An operation is Make's unit and equals one module run, per Make's docs. They are not interchangeable in size, so comparing plan prices without mapping your workflow to each unit is how teams get surprised by a bill.

Is a workflow the same as an integration?

No. An integration is a connection between two tools so they can exchange data. A workflow is the sequence of triggers and actions that uses one or more integrations to do a job. You can have an integration in place and no workflow running on it yet.

What does webhook-triggered mean, in plain terms?

It means the workflow starts the instant an event happens, because the source system pushes a message to it, rather than the workflow checking on a timer. Webhook-triggered is faster and lighter than polling when the source supports it.

Do I need to understand any of this to work with an automation team?

No, but knowing the words helps you read a proposal and catch what is missing. If a plan for a high-volume, money-touching workflow never mentions idempotency, error handling, or monitoring, that is worth a question before you sign.

What is the difference between RPA and workflow automation?

Workflow automation connects systems through their APIs, the sanctioned doors built for this. RPA mimics a human clicking through a screen and is a last resort for systems that expose no API. API-based automation is more reliable when it is available, which is most of the time.

Where does AI actually fit into automation?

AI handles the fuzzy steps that rules cannot: reading unstructured text, extracting fields from messy documents, classifying and drafting. The reliable pattern wraps the AI in structure, retrieval to ground it, validation to check it, and a human in the loop for anything costly or hard to reverse.

How do I know if a workflow is cheap or expensive to run?

Multiply the steps in the workflow by how many times it runs a month, then map that to the platform's billing unit, tasks on Zapier or operations on Make. A three-step workflow at 1,000 runs is roughly 3,000 tasks. Do that math before you pick a tool, and read our full cost breakdown.

You do not need to memorize every word here. You need enough to read the next proposal without nodding at things you cannot see, and to catch the day a vendor's cheap-looking demo hides an expensive bill or a missing failure path. When you would rather have the workflow designed, built, and kept running by people who do this every day, start a project with bottta.