Docs / Start here
Will your automation work here?
Go through your list before you build anything. Twenty minutes, and you will know which one to start with.
The three questions
Take each automation your team has built and ask these.
1. Can it reach what it needs through an API, a database, a spreadsheet, or an MCP server?
An API is a way for one system to let another system fetch or change data without a person clicking anything. Most business software has one, including plenty whose vendor talks about "integrations" rather than APIs.
An MCP server is a ready-made bridge that exposes another product's tools to AI systems. If your team already runs one on a laptop, it can be connected here.
What passes: An invoice reconciliation that reads from your finance system's API and a Google Sheet of purchase orders.
What does not: Anything where a step only works by a person logging into a website and clicking through its screens. There is no browser automation here, on purpose, because a system driven by clicks leaves no record anyone can check afterwards.
2. Is it acceptable for a person to approve the changes it makes?
Anything that changes another system waits for someone to approve it. Reading does not.
What passes: An agent that reads invoices, works out the discrepancies, and prepares a supplier query for the finance lead to send.
What needs rethinking: An agent that posts fifty supplier queries overnight with nobody looking. It will run, and fifty approvals will be waiting in the morning.
3. Can you describe the work as stages, each with something it must have achieved?
Not the steps it takes, but what has to be true before it moves on.
What passes: For invoice exceptions, the stages are "we have the invoice and the matching purchase order", then "we know what the discrepancy is", then "we know whether the contract allows it", then "the query is written and ready to send". Each of those is checkable.
What needs rethinking: "it looks at the invoices and sorts them out". That is one stage, and you have no way of knowing whether it worked.
Three yeses and it moves as it is. Start with the biggest one, because you already know how it should behave, which makes it the cheapest thing to learn on.
When the answer is no
Most nos are about how the job is put together rather than what it does.
It logs into a website and clicks through the screens
Example: Somebody's script signs into a supplier portal, opens the statements page, and copies the outstanding balances into a spreadsheet.
What to do instead. Find out whether that supplier has an API. They usually do.
You do not have to read their documentation and write anything by hand. In the Connections workspace, create a connection pointing at the system and press Discover. It looks for the standard places a system publishes its API description, checks what it finds, and brings back a list of things you could enable. You can also paste one page of their documentation and have it read that instead. For a database, it looks at the tables and tells you what your login is actually allowed to do.
Nothing switches on by itself. Everything found comes back for you to confirm.
If there genuinely is no API, keep that one step with a person and let the agent do everything either side of it.
It writes to another system overnight with nobody watching
Example: A script that posts every unmatched invoice back to the supplier at 2am.
What to do instead. Let it run overnight and gather everything, but have it prepare one approval containing all fifty queries rather than fifty separate ones. One thing to read and approve in the morning is a decision somebody actually makes. Fifty get waved through, and then the approval step is pointless.
In practice this means putting the change in the last stage of the script, so the run does its reading and thinking first and stops at the end.
It runs over thousands of records
Example: A monthly job over 4,000 invoice lines.
What to do instead. Two options, for two different problems.
If the work on each record is small, a function step can repeat itself across a list: it runs once per item, eight at a time, up to a thousand items. One slow or failing item does not stop the rest, it just gets recorded as failed in the results.
If the work on each record is substantial, make the unit smaller: one run per invoice, or one per batch of ten, on a schedule. See Limits and run behaviour for the ceilings and why they exist.
It needs to start when something happens elsewhere
Example: Run when a new invoice lands in the finance system.
What to do instead. Two options. If the other system can call out when something happens, point it at your agent, which can be triggered by your own software. If it cannot, check on a timer: run every fifteen minutes and work out what is new since last time. For anything that happens during business hours, nobody notices the difference.
It produces a Word document, or reads a scanned PDF
Example: The monthly exceptions report, as a formatted document.
What to do instead. Connect an MCP server for a document service, and its tools become operations like any other. See Connection types.
What to leave where it is
It must carry on from where it stopped after a failure. A run that stops does not resume. You get a record of exactly what finished, and re-running is your decision. If the job cannot tolerate that, leave it.
Nobody may ever look at it, and it changes things. If the whole point is that no human is involved and it writes to a system of record, this is not the right home for it.
You're done when
- Every automation on your list is marked as moves now, needs rearranging, or leave it.
- For each one that needs rearranging, you know what you would change.
- You have picked the one you are building first.