Automation terms, in plain English
The technical terms used on this site, defined plainly. Written for the person signing the invoice, not the person writing the code.
Most automation vocabulary is either jargon used to sound expert or ordinary words used in a specific way. Both are a problem when you are trying to compare two proposals. If a vendor uses one of these terms and cannot explain it as plainly as it is explained here, that is worth noticing.
All 38 terms
API
A defined way for one piece of software to ask another to do something or hand over data. It is the front door built for programs rather than people. When a vendor says "it has an API", they mean a proper integration is possible. When they say "there's no API", the options get slower, more fragile and more expensive. See RPA.
Webhook
A system pushing you a message the moment something happens, rather than you asking repeatedly whether it has. An order is placed and the shop tells you immediately. Webhooks are faster and cheaper than the alternative, which is polling. Not every system offers them, and not for every event.
Polling
Asking a system "anything new?" on a schedule, because it will not tell you unaided. Every check costs a request whether or not there is anything to collect, which is why polling competes with your rate limit and why webhooks are preferred where they exist.
Rate limit
A cap on how many requests a system will accept in a period, per minute, per day, or as a budget you spend. It is not an obstacle to be defeated; it is the vendor protecting a shared service. It matters because it shapes design. A build that ignores the limit works in testing with ten records and fails in production with ten thousand.
Connector
A pre-built bridge between an automation platform and a particular application, so the integration does not have to be written from scratch. Connector quality varies enormously, and "there's a connector" does not mean it covers the specific operation you need. Worth checking at the level of the action, not the app.
OAuth
The standard way an automation is granted access to a system without being handed a password. You approve specific permissions and the automation receives a token it can use. Tokens expire, which is the single most common cause of an automation that worked yesterday and is dead today.
Two-way sync
Keeping two systems in agreement when either can change. Far harder than it sounds and routinely underestimated, because it demands an answer to the awkward question: when both sides changed the same record, who wins? That is a distributed-systems problem, not a copy operation, and it is the one item that most often leaves a fixed price list for a quote.
Field mapping
Deciding which field in one system corresponds to which field in another, including where the answer is "nothing". Dull, and the place where migrations go wrong. It should be written down and signed off before anything is built, not inferred during.
Deduplication
Recognizing that "Acme Ltd", "ACME Limited" and "acme" are one company, and not creating a third record. Every system that accepts inbound data needs a deduplication rule; without one, an automation industrializes the mess rather than fixing it.
Exception
A case the normal path does not cover. The customer who is invoiced differently, the order that skips approval, the supplier who sends a photograph of a receipt. Exceptions are not edge cases to be tidied away. In most builds they are the majority of the engineering, and the main reason quotes move after someone actually watches the work.
Error handling
What the automation does when a step fails: whether it stops, retries, routes to a person, or carries on. An automation without it does not fail cleanly. It fails silently, which is worse, because you have stopped watching the thing it replaced.
Retry logic
Trying again after a failure, sensibly. A network timeout deserves another attempt; a rejected record does not. Retries must be paired with idempotency or they become a way to do the same thing twice.
Idempotency
The property that doing something twice has the same effect as doing it once. The most important word on this page and the least known. Without it, a timeout followed by a retry posts the invoice twice, and nobody notices until a supplier is paid twice or the reconciliation refuses to balance. Ask any vendor building against your accounting system how they guarantee it.
Silent failure
The automation stops or produces wrong output and nothing announces it. The dangerous failure mode, because the manual process it replaced is gone and nobody is checking. Good builds are loud when they break.
Parallel run
Running the automation alongside the manual process for a period and comparing the two before cutting over. The step most often proposed for removal to save time, and the one that catches the cases nobody mentioned while the old process is still there to catch them. Testing proves it handles the cases you thought of; a parallel run proves it handles the ones that actually occur.
Execution log
The platform's record of each run, usually including the actual data that passed through. Useful for debugging and a quiet data-retention decision: the default retention is often longer than you would choose. Set it deliberately.
AI agent
Software that interprets something unstructured (a message, a document, a call) and then acts in your systems on what it worked out. The acting is what separates it from a chatbot, and it is where both the value and the risk live.
Chatbot
Answers questions and hands the answer to a person. Older decision-tree versions follow fixed branches with no language understanding at all, which is genuinely the better choice for narrow, predictable jobs.
Evaluation set
A body of real cases from your own history, each with a known correct answer, used to measure how often an AI component is right. The single artefact separating a system from a demo. If a vendor cannot tell you the size of yours and who labeled it, they are quoting on hope.
Confidence threshold
The level below which the agent stops and asks a person instead of answering. A business decision, not a technical one: set it high and the agent is nearly always right but hands over often; set it low and it handles more and is wrong more. There is no correct setting in the abstract.
Deferral rate
How often the agent declines and passes to a human. The number nobody asks for and the one that determines your actual saving. An agent that is 95% accurate but defers 40% of cases is automating 60% of the work, and the business case has to be built on 60%.
Structured output
The model returning typed fields your systems can act on (a category, an amount, a reference) rather than a paragraph someone has to read and re-key. What makes an AI component usable inside an automation rather than beside one.
Hallucination
A model producing something fluent, confident and untrue. Not a bug to be patched out; a property of the tool. It is managed with retrieval from your own material, structured output, confidence thresholds and a human step before anything irreversible, not with a promise that this model does not do it.
Retrieval
Fetching the relevant passages from your own documents and giving them to the model with the question, so the answer comes from your material rather than the model's memory. Also the main lever on running cost: sending a whole price list on every message costs several times sending the relevant section.
Straight-through processing
The share of items handled start to finish with no human involvement. A realistic target for document work after tuning is 75% to 90%. Anyone promising 100% has not counted the exceptions.
Review queue
Where items go when the automation is not confident enough to proceed. Its design decides whether the whole build survives: a spreadsheet of flagged numbers gets abandoned within a fortnight and the work reverts to manual. A real queue shows the document, the extracted values, the reason it was held, and one-click accept or correct.
Three-way matching
Checking an invoice against both the purchase order and the record of what was actually received, rather than the purchase order alone. Meaningfully harder than two-way matching, and one of the three things that pushes invoice processing out of a single fixed price.
Matching tolerance
How close is close enough. "Within 2% or $25, whichever is lower" is a common answer. There is no universally correct one, and being wrong in either direction is costly: too tight and everything lands in the queue, too loose and overcharges sail through.
EDI
An older, structured way of exchanging business documents, still standard in logistics and retail supply chains. Entirely workable and not the same job as calling a modern API: different formats, trading-partner agreements, often an intermediary in the middle. If your connectivity is EDI-based, say so before anyone quotes.
Tokenization
Replacing a sensitive value, typically a card number, with a reference that is useless if leaked. The correct approach to payments in an automation: work with the token, never the number. An automation that never sees a card number cannot leak one.
RPA
Robotic process automation: software driving the user interface, clicking and reading the screen as a person would. It exists for systems with no other way in. It breaks whenever the screen changes, so it is the fallback rather than the default, and a proposal that leads with it should explain why the API route is unavailable.
Orchestration
The layer that decides what happens in what order across several systems, as distinct from the work any one system does. Keeping orchestration outside your CRM or accounting package is why it stays legible; putting it inside produces sixty undocumented rules nobody can see at once.
Self-hosting
Running the automation platform on infrastructure you control instead of the vendor's. Removes per-operation pricing and the vendor from the data path, which matters for data residency. It is not free: somebody has to patch, back up and monitor the server, and that time is the real cost.
Scoping
Establishing what would actually be built and what it would cost, before anybody builds it. Done properly it involves watching the work rather than asking a manager to describe it, because the description and the reality reliably differ. Ours is a thirty-minute call and a written proposal within two business days, and it is free.
Governor limits
Salesforce's name for hard caps on what a single operation may consume. Similar constraints exist elsewhere under other names. They are the platform protecting itself from one tenant's bad code, and bulk work must be designed for them.
DLP policy
Data loss prevention: rules set by your IT administrators governing which services may exchange data with which. Common in Microsoft environments and able to block an automation outright regardless of how well it is built. Find out early rather than at deployment.
BAA
Business associate agreement: the contract required under US health privacy rules before a vendor may handle protected health information. Every component in the chain needs one, which rules out several mainstream platforms at their standard tiers and sometimes forces self-hosting. It shapes the design from the first hour rather than being a disclaimer at the end.
Takeover assessment
Inventorying automations somebody else built: what exists, what each touches, which credentials it uses, what is fragile. The prerequisite to responsibly promising to keep them running. Ours is free, and you keep the documentation.
No term matches that. Try a shorter word, or just ask us.
Read a proposal that uses one of these badly?
Send it over. We will give you a written second opinion on scope, assumptions and price, and it costs nothing, including when the answer is that the quote is fair.
You will talk to Fayez or Kareem. Nobody else.