Our IT Person Built All Our Automations and Then Left — What Do We Do Now?

Detailed Explanation

This is one of the most common ways a small business discovers it has an automation problem: something breaks, or someone asks "who set this up?", and the honest answer is that the one person who understood it doesn't work there anymore. If nothing was documented and nobody else has admin access, there may be no clean way in to even see what exists, let alone fix it.

What makes this urgent rather than merely inconvenient is that several automation platforms don't wait for you to notice — they start a clock the moment an account is deactivated or removed. This page covers what actually happens on the platforms most small Australian businesses use, and what to do in the first days after realising you're in this position.

What Actually Happens, Platform by Platform

Power Automate. Microsoft's own support documentation describes what it calls an "orphaned flow" — a flow with no valid owner, typically because the owner's user account was disabled or deleted. If a flow relies on that person's authenticated connections, it can start failing immediately once their account is deactivated, because the underlying identity behind the connection is no longer valid. If nobody adds a co-owner or transfers ownership, Microsoft's documentation states the flow is disabled after 14 days.

Reassigning ownership isn't always straightforward, either. A solution-aware flow (one built inside a Power Platform solution) can have its owner changed directly by an existing owner, co-owner, or an admin. A non-solution-aware flow — which is how most simple, ad-hoc flows get built — cannot have its owner changed in place, because the owner is part of the flow's identity. The practical workaround is exporting the flow and re-importing it as a new flow under the new owner (or moving it into a solution first, if your environment has Dataverse), and exporting and recreating a flow this way loses its run history. If the new owner doesn't hold the same premium licence the departed person had, Microsoft's documentation describes a 30-day grace period before Power Automate turns the flow off.

n8n (self-hosted). A self-hosted n8n instance doesn't have an "owner leaves the organisation" concept in the same way a cloud SaaS platform does — the bigger risk is that whoever had server and admin access has left, and if nobody else has it, you may be locked out of the instance entirely rather than locked out of a single workflow. Separately, n8n's own documentation states that by default, execution data — the record of what a workflow actually did each time it ran — is pruned once it's older than 14 days or once the total stored executions exceed 10,000, whichever happens first. That means the forensic trail of exactly what a departed person's workflows were doing in the weeks around their departure may already be gone by the time you go looking for it, unless those defaults were changed.

Zapier and Make. Both tie workflows to the account that created them in a broadly similar way to Power Automate's non-solution-aware flows. Check each platform's current documentation for its specific reassignment process rather than assuming a fast, clean handover — this is exactly the kind of platform detail that changes without much notice, and getting it wrong (or discovering the limitation mid-crisis) costs more time than checking it in advance.

What to Do This Week

1. Find out what platform, or platforms, are actually in use. If nobody left a list, check billing records, browser bookmarks, email confirmations, and ask remaining staff what tools they've seen referenced. You cannot secure what you don't know exists.
2. Get admin or owner-level access restored first, before touching individual workflows. If the departed person was the sole admin on a platform account, resolving that access gap is the actual first step — everything else depends on it.
3. Add a co-owner to every business-critical workflow immediately, even before you fully understand what each one does. This is the single fastest way to stop the countdown some platforms have already started, and it costs nothing to do defensively.
4. Inventory what's running before you change anything. List every active workflow, what it appears to do, and what accounts or credentials it depends on — see how do you securely manage credentials and connected accounts in an automation platform for the credential side of this specifically.
5. Prioritise anything customer-facing or financial. A workflow that emails customers, processes payments, or touches invoicing is worth understanding and stabilising before an internal notification flow that nobody will notice if it quietly stops.
6. Document as you go, this time. Every hour spent reverse-engineering an undocumented flow is an hour you can capture in a write-up so this doesn't happen again — see how do you document an automation workflow so someone else can maintain it for what to actually record.

Things to Consider

• This is a remedial problem with a clock already running, not a planning exercise. If you're reading this before anyone has left, the more useful page is the preventive one — see how do you document an automation workflow so someone else can maintain it — because avoiding this situation is far cheaper than recovering from it.
• A departure is a natural moment to ask who should own automation going forward, not just this specific mess. See who should own automation projects in a small business for whether a single-person, informal ownership model is the right structure to return to once this is resolved.
• Switching platforms entirely is sometimes raised in the panic of the moment — check the actual exit cost first. See how do you avoid vendor lock-in when choosing automation tools for what data and configuration actually needs to move if you do decide a platform change is warranted, rather than assuming a clean break is simple.
• If the business is on a self-hosted platform, confirm who actually controls the server, not just the workflows on it. Losing the one person who had SSH or hosting-provider access is a different, more serious problem than losing the owner of an individual cloud workflow — see what does n8n actually cost — cloud vs self-hosted for the trade-off between paying a vendor to hold that responsibility versus a single internal person holding it.

Common Mistakes

• Waiting until something visibly breaks before acting. Several platforms' countdowns start the moment an account is deactivated, not when a workflow first fails — by the time something breaks, part of the response window may already be gone.
• Assuming ownership can always be reassigned cleanly. As the Power Automate example shows, a flow built the ordinary way (not inside a solution) often cannot have its owner changed in place at all — the workaround is more disruptive, and loses history, compared to a simple reassignment.
• Rebuilding from scratch before checking whether a transfer or export path exists. Recreating a workflow the departed person spent real time getting right is slower and riskier than transferring or exporting it, when either option is available.
• Not checking whether execution history has already been quietly deleted. On a self-hosted platform with default retention settings, evidence of exactly what a workflow was doing in the weeks around the departure may already be gone by the time anyone thinks to look — don't assume the history is sitting there waiting to be reviewed.
• Treating this as purely an IT problem rather than a business-continuity one. The workflows at risk often touch customers, payments, or compliance-relevant records — prioritise based on business impact, not on which workflow happens to be easiest to understand first.