This article is for the person responsible for how the company runs, who has automations built in n8n, Make, Power Automate or in code — and is asking: what happens when the person who built this leaves? It is not an article about building in-house versus hiring someone. The checklist at the end works the same for an automation built by an employee, by a freelancer or by us at ploch.ai. We describe how the platforms behave from their documentation as at 12 October 2026; the sources are at the end.
An automation is a program that breaks quietly
A no-code automation looks like a setting in a tool, but it behaves like any other program. It connects to services through an API (the interface other software uses to work with a system and its data), and depends on accounts, passwords, other people’s systems and service versions that change without asking you. If only the person who built it knows about it, it has one maintainer — and nobody else knows it exists.
On top of that, an automation rarely fails loudly. There is no red screen. Invoices simply stop reaching the accounting system, and somebody notices at month-end close.
Seven ways an automation silently stops working
The table is the backbone of this article. The “who usually notices” column describes the situation without a prepared handover. “Implementer” is a role, not a company: the person who fixes and tests — an employee, a freelancer or an outside firm. We describe repair effort at three levels: small — renewing access or changing a setting, with no change to the automation’s steps; medium — fixing a selected step; large — rebuilding several steps or reassessing the whole process on real cases. After every repair the result of the whole process is checked; how much to test depends on what the change affects.
| Failure | Symptom | Who usually notices | Who acts | Repair effort |
|---|---|---|---|---|
| 1. Expired or revoked access | Steps that connect to a service return a permission error | Whoever is missing data at the end of the process | Person responsible for systems | Small: reconnect the account and check one run |
| 2. Automation switched off by the platform or after a move | Nothing happens — no errors, because there are no runs | Whoever is missing data at the end of the process | Implementer | Small to medium: remove the cause, check what was partly done, only then switch it on and catch up on the backlog |
| 3. API change in a connected system | Errors in one step, or empty fields in the result | Whoever receives error alerts — if they were set up | Implementer | Medium: fix the connection and test the process |
| 4. Retired AI model version | An error after the retirement date; before it, a different result after a model switch | Whoever opened the account — if the provider sends an e-mail warning | Implementer with the process owner | Large: retest the process on the new model |
| 5. Exhausted plan limit or price change | Depending on the platform and plan: runs paused until the limit is raised, extra-usage charges, or a higher plan fee | Whoever is missing data, or finance when reviewing costs | Person responsible for systems | Small to medium: change the plan or reduce usage |
| 6. New layout of the document or input data | Empty or shifted fields, although the run “succeeded” | Process owner, at a manual check | Implementer | Medium: adjust the extraction and add the example to the tests |
| 7. Quality drop without any error | More and more manual corrections, answers that are “nearly right” | Process owner — if they measure | Process owner with the implementer | Medium to large: check a sample of results, fix the instructions or rules and test |
The details below decide whether a given failure is noticed within an hour or within a quarter.
1. Access expires for reasons nobody plans. An automation stores access to services — a password, a key or a token, a digital pass issued by the service. With Google accounts this is often a refresh token: a pass that lets the automation renew access without approving the connection again. Google’s documentation lists reasons a refresh token stops working, among them: the user revoked access, the token was not used for six months, or the user changed their password and the access includes Gmail. An app configured in Google Cloud for users outside the organisation, with the publishing status “Testing”, receives a token valid for seven days unless it asks only for basic profile data. An automation connected in a hurry “for now” can therefore stop working after a week.
2. The platform can switch an automation off by itself. In Make you set how many errors in a row a scenario may hit before it is deactivated, but a scenario started by an instant trigger — a step that starts the scenario as soon as an event arrives, for example a webhook, an automatic notification from another system — is deactivated after the very first error that no error handler set up in the scenario catches. In n8n, simply moving an automation to another installation through source control (keeping successive versions of automations outside n8n) does not guarantee that it will run: on the target side you have to check that publishing — manual or automatic during the pull — succeeded, because it can fail, for example when access credentials are missing. A switched-off automation produces no errors — which is why this failure is easy to miss.
3. Connected systems change their APIs. An example from recent weeks: Microsoft removed
version 1.0 of the Business Central API in its 2026 release wave 1 (version 28.0 and newer). On 18
September 2026 Make published a notice that scenarios with connections manually set to the
/api/v1.0/ endpoint would stop working and had to be switched to /api/v2.0/. The notice went to
Make’s help centre — someone had to read it.
4. Providers retire model versions. The risks this creates and why the process then needs retesting from scratch are covered in our article on what implementing AI costs. One thing matters here: who gets the warning and how much time they have.
| Provider | Notice before retirement and how it is given (as at 12 October 2026) |
|---|---|
| OpenAI | at least 6 months for generally available models and at least 3 months for their specialised variants; preview models can be retired much sooner — OpenAI gives 2 weeks as an example; sooner also for safety or compliance reasons; e-mail to active customers and a documentation entry |
| Anthropic | at least 60 days for publicly released models; e-mail and a documentation entry |
| Google (Gemini API) | the dates in Google’s table are the earliest possible; Google announces the exact date in advance |
If the provider sends the warning by e-mail and the automation’s author opened the account on their own address, the warning will go to someone who is no longer at the company.
5. The plan limit or the price list changes during the year. Make bills in credits; when they run out you can upgrade, buy extra credits or turn on automatic purchasing. Make says automatic purchasing is meant to keep scenarios running once the limit is reached; extra credits cost 25% more than the credits in the plan. In n8n, on the Business and Enterprise plans automations keep running after the execution quota is exceeded, but overage charges may apply. Both show up only on the invoice if nobody watches usage. A price change on its own does not stop the automation, but it changes the arithmetic the decision to build it rested on — which is why it belongs in the same table.
6 and 7. A new document layout and quality drift are failures without an error. The platform counts the run as successful, because every step executed — except that a date landed in the “amount” field. Such failures are caught by a person who knows the process, or by a rule that checks the result — provided it can be written down, for example “net plus VAT equals gross”. In n8n such a rule routes the run to a Stop and Error step, which marks the run as failed; the assigned error-handling automation then runs and sends the alert. If simple rules are not enough to assess quality, a person needs to review a sample of results; automated checks can only support that review. How to plan that is covered in our article on human oversight of automation.
When the author leaves: why nothing gets fixed
The author leaving is not an eighth failure. It is the reason each of the seven ends in a longer outage, because nobody knows where to look. On top of that come three traps described in the platforms’ documentation:
- Connections that depend on the author’s account. In Make, a person deleting their profile chooses whether to delete the connections they created as well. If they do, every scenario using those connections stops working. A connection linked to a private Google or Microsoft account also depends on that account still existing and on the company having any control over it.
- A flow without an owner. Microsoft describes Power Automate flows that, after their owner leaves, have no valid owner and can stop working if they use connections tied to that person’s account. When the owner leaves, the flow drops to lower performance. The Power Automate licensing FAQ adds that the owners are then notified and, if nobody acts, the flow is turned off after 14 days. Separately, Microsoft’s limits page describes turning off, after 14 days, flows whose trigger or actions fail continuously, or which the platform keeps slowing down because they exceed its limits. After the owner leaves, it is worth checking straight away that the flow works correctly. An administrator can assign a new co-owner, but that is only the start: the connections and the licence the flow runs on also have to be checked.
- Alerts to a mailbox nobody reads. Errors, model-retirement warnings and API-change notices go wherever the author pointed them.
In n8n, when moving automations through source control, n8n sets the owner by matching the e-mail address; if that person is not on the target installation, whoever does the move becomes the owner.
Who is responsible for what after go-live
Our guide on how to implement AI has a table of roles for the project. The one below covers the time after go-live — the months and years in which nobody thinks of the automation as a project any more.
| Task after go-live | Process owner | Person responsible for systems | Implementer |
|---|---|---|---|
| Checks a sample of results and reports quality drops | responsible | — | helps find the cause |
| Looks after access, accounts and their renewal | — | responsible | says which access is needed |
| Follows changes in connected systems and provider notices | — | responsible | assesses the impact and fixes |
| Tests the process after a model or system change | approves the test result | — | runs the test |
| Decides to retire the automation | responsible | advises on cost | advises on effort |
| Owns the maintenance budget | responsible | provides usage data | estimates hours |
In a small company one or two people combine the three columns, and that is fine — as long as every cell marked “responsible” has a person’s name in it.
What must stay in the company: the handover checklist
This checklist reduces dependence on the original author and lets the company take control of the automation. The technical minimum for self-hosted n8n — an encryption key stored off the server, a tested restore from backup and updates — is covered in our n8n guide and not repeated here. Below is what applies on every platform.
- An inventory of automations with a business owner for each. Name, what it does, which systems it connects to, who in the company is responsible for the result. An automation with no owner in the inventory is the first candidate for retirement.
- An inventory of access on accounts the company controls. Every connection to another service set up on an account the company has control over — where the platform allows it, a technical account (a company account created for the system rather than for a specific person), not an employee’s private account. For connections that have to be tied to a specific person, a written and tested procedure for replacing them. For every access that expires, its expiry date.
- The contact address with providers set to a shared mailbox. Platform and model-provider accounts with a notification address that more than one person reads — regardless of whose account the automation connects with.
- Exports and version history. A current copy of every automation outside the platform — details for three platforms in the table below. When using Git (a system that stores successive versions of files) in n8n, also check that the handed-over version matches the one running day to day: the latest saved version may contain unpublished changes.
- Alerts to a shared channel — including when something did not happen. On every platform the error alert goes to the team’s channel, not to one person, and has someone who acknowledges it and escalates. In n8n this is an error-handling automation that starts with the Error Trigger step, assigned to every automation in daily use; one can serve many automations. Because a switched-off automation reports no errors, you also need a check on the expected result that runs independently of it: for example a daily summary of the number of runs, in which both zero on a day when work was expected and a missing summary are alarms.
- Rules that check the result. Where a wrong result does not cause an error (rows 6 and 7 of the table) and the condition for correctness can be written down, the automation checks the result itself and marks the run as failed. A person checks the remaining cases on a sample.
- A tested restore. A backup from which someone in the company has actually restored the automation — access credentials included.
- A deliberate decision on storing and retaining run data. Check which run data the platform or code stores, where it is kept and which settings limit storage and retention — a decision to make for each automation. How this works in n8n and what it means for the GDPR (the EU General Data Protection Regulation) is covered in our n8n guide.
- A checked licence. Whose licence the automation runs on and whether the licence allows the way it is used. In Power Automate an automated or scheduled flow runs on the owner’s licence unless it has a separate Process licence assigned; in n8n the free edition’s terms are set by the Sustainable Use licence.
- A one-page runbook for each automation. What it does, where it takes data from, where it sends it, who approves it, how to tell it has stopped working, how to switch it off safely and how to catch up on the backlog without creating duplicate entries.
Exports and versions: n8n, Make, Power Automate
| Platform | What you can do without paid add-ons | What is paid or limited | What the export does not contain |
|---|---|---|---|
| n8n | Download an automation as a JSON file (a text record of all its steps and settings); version history for the last 24 hours | Version control through Git on the self-hosted Business plan and on Enterprise; 5 days of history on n8n Cloud Pro, full history on Enterprise | Stored credentials — the file has only their names and IDs; with Git, credential “stubs” (ID, name, type) are moved, plus other fields only when they are formulas (so-called expressions) — so what n8n writes to Git needs reviewing and keeping somewhere that is not public |
| Make | Export a scenario as a blueprint, a file describing its steps, settings and how data is assigned to fields; saving scenario versions and restoring them from the history (on all plans) | A saved version is kept for 60 days, except the latest, which Make keeps until a newer one is saved | Connections: they have to be created again after import |
| Power Automate | Export a solution (a package containing the flow and related components) as a ZIP file | Changing the primary owner works only for a flow inside a solution; a co-owner must first add a flow outside a solution to one, or export and import it as a new flow | Connections: the solution contains connection references, and on import you point them at connections in the target environment |
Two conclusions. First, the export alone is not enough to restore access — which is why item 2 on the checklist matters as much as item 4. Second, “without credentials” does not mean “without secrets”: n8n warns that an HTTP Request step (one that sends a request to another system), created by pasting a ready-made command, may contain a password or key copied in with that command. An n8n export file may also contain data pinned to steps, meaning data saved on them for reuse during testing. This can be real customer data. Before sharing an export with anyone outside the company, check that step settings contain no passwords or keys, and remove or anonymise the pinned data and the names of stored credentials (which can include, for example, a client’s name).
When the model in an AI step changes: what to recheck
Changing the model — forced by a retirement or chosen for a lower price — is a change to the program, even if only one field in the automation changes. Before switching, check:
- the results on the same sample of real cases the automation was accepted on, including the hard and unusual ones;
- the response format — whether the next steps receive fields in the same layout;
- the share of cases sent to a person;
- the cost of one run after the change.
A retirement cannot be postponed, but it can be planned: the notice in the table above is time for the test, provided the warning reaches the right person.
What to add to the yearly budget
We do not give amounts, because they depend on the process. We give formulas and the places the numbers come from. The categories of running costs are covered in our article on what implementing AI costs, and a full twelve-month bill for an AI agent (software that carries out the steps of a task in your systems) in the article on what an AI agent costs.
| Line | Yearly formula | Where the numbers come from |
|---|---|---|
| Platform | monthly plan price × 12 + charges for usage above the limit | The platform’s price list and usage panel (executions in n8n, credits in Make) |
| AI model | calls per month × average cost per call × 12 — excluding calls whose model-usage cost is already included in platform credits (e.g. with Make’s built-in AI provider) | The provider’s price list and a few months of invoices |
| Quality checks | hours per month × 12 × the checker’s rate | The process owner’s time reviewing a sample of results |
| Retests after a model change | model changes per year × hours per test × rate | Providers’ model-retirement pages and the time one test takes |
| Fixes after system changes | for each connected system: expected changes per year × hours per fix × rate | Those systems’ provider notices |
| Access renewal | renewals per year × hours per renewal × rate | The access inventory from item 2 of the checklist |
| Handling alerts and failures | hours per month acknowledging alerts, finding causes, handling exceptions and catching up on missed runs × 12 × rate | The alert and failure history of recent months, or the implementer’s estimate |
| Own server (if applicable) | (monthly server cost + monthly backup cost) × 12 + yearly hours of updates and restore tests × rate | The server and backup storage invoices and the administrator’s time |
Assign each hour of work to one line so it is not counted twice. Once the lines are filled in, you can also see whether the automation pays for itself.
When maintenance means retiring the automation
An automation is worth retiring when the yearly total from the table exceeds the value of the time it saves, or when there is no process owner to say whether the result is correct. It is the same rule we apply before building: “the saving does not cover the running cost” is one of the reasons we turn a project down. Retiring is also a decision to plan: who takes the work back by hand, what happens to the run data and which access has to be revoked.
An afternoon audit: ten questions
Someone managing the company can ask these without reading any code. Every “I don’t know” is an item to fill in.
- Do we have an inventory of all automations, including the ones built “for now”?
- Does each one have a business owner with a full name?
- Does any connection depend on an employee’s private account, or on an account the company does not control?
- Which address receives e-mails from the platform and from model providers?
- Where does the alert go when an automation ends with an error — and who last saw one?
- Is any automation switched off without anyone noticing?
- Do we have a current export of every automation outside the platform?
- Has anyone ever restored an automation from a backup?
- What did the platform and the model cost last year — and has anyone compared that with the time saved?
- Is there a one-page runbook for each automation that someone who did not build it could use?
How we hand over code, configuration and documentation after an implementation is described in our implementation methodology; what a whole automation project looks like, from choosing the process to maintenance, is on the page about AI automation for business.
Sources, as at 12 October 2026
- n8n Docs — error handling (Error Trigger, Stop and Error); read 12 October 2026.
- n8n Docs — source control and environments and push and pull changes — Business and Enterprise availability, credential stubs, publishing and owner after a move; read 12 October 2026.
- n8n Docs — export and import and change history and pinning data; read 12 October 2026.
- n8n pricing — plans, Git version control on the Business plan, overage charges on the Business and Enterprise plans; read 12 October 2026.
- n8n licence FAQ — the Sustainable Use licence; read 12 October 2026.
- Make Help Center — scenario settings (deactivation after errors), blueprints, scenario version control (available on all plans per Make’s announcement), deleting your profile, credits and extra credits; read 12 October 2026.
- Make Help Center — Business Central: action required for connections using API v1.0 — notice of 18 September 2026; read 12 October 2026.
- Microsoft Learn — orphaned flows when the owner leaves, change the owner of a cloud flow, Power Automate licensing FAQ, flow limits, export a solution and connection references; read 12 October 2026.
- Google for Developers — OAuth 2.0, refresh token expiration; read 12 October 2026.
- OpenAI — deprecations, Anthropic — model deprecations and Gemini API — deprecations; read 12 October 2026.