Someone at your company owns your automation, and they can quit
Not the license. The connection. Whoever signed in when the workflow was built owns it, and disabling their account on their last day kills it. What actually breaks, why it stays hidden for weeks, and how to give automations an identity of their own.
Someone at your company owns your automation, and they can quit
Not the license. The connection. When a workflow reads a mailbox, writes to a drive or updates a CRM record, it does so as a person, and that person is on the payroll right up until the day they are not.
We see this most often at companies that got security right. Offboarding is tight, accounts are disabled on the last working day, access reviews happen on schedule. Then a workflow that has run untouched for months goes quiet, and it takes a fortnight and a customer complaint before anyone links the two events.
What the platform actually stored
Building a connection in Make, n8n or Power Automate opens a sign-in window. Whoever types their password there grants the access. The platform receives a refresh token bound to that account, and every action the workflow takes afterwards runs under that person's name and permissions.
Disable the account and the token dies with it. Entra ID revokes on account disable and on password reset, and with Continuous Access Evaluation switched on that happens in minutes. Google Workspace withdraws every granted authorization when an account is suspended. There is no grace period built in for your automation, and there should not be.
You do not even need a resignation. A password reset after a phishing scare will do it, so will re-enrolling multi-factor authentication when someone loses a phone. Neither event ever gets routed past the team whose process depends on it.
Output ownership fails the same way. Files a workflow writes through a personal account into My Drive or OneDrive belong to that account. Delete the user once the retention window closes and the files go with them, unless somebody transferred them first. For delivery notes, invoices or patient correspondence, that is a retention problem rather than an inconvenience.
The gap that hides it
Failure arrives late. Weekly and monthly workflows can sit dead through a full cycle before anyone notices, and conditional ones break only when the condition next fires.
The signal is quiet as well. A 401 from the target system, one failed execution in a log nobody opens, and on several platforms a connection that still shows as healthy because its status only refreshes on the next call.
Responsibility falls between two teams. IT works a checklist of hardware, account and license. Nothing on that list records which business processes ran through the account, because that knowledge sits in operations. Operations has no reason to treat a resignation as a technical event.
Give the automation an identity of its own
A tighter offboarding checklist only gets you so far. The work belongs under an identity that nobody owns personally and that cannot hand in notice.
On Microsoft 365 that is an app registration in Entra ID with its own permissions. It needs no license, its scopes can be narrowed to specific mailboxes and folders, and no staffing change takes it away. Send and receive through a shared mailbox, which is free up to 50 GB.
On Google Workspace a service account does the same job, provided you move the output too. Files belong in a shared drive, because leaving them in an individual's My Drive just relocates the original problem. Use a group address as sender and recipient so replies reach more than one inbox.
Keep the permissions tight while you are at it. Service accounts with tenant-wide admin rights are a common sight, usually because that raised the fewest questions during setup. An account with no expiry date and no human attached is exactly the one that should be scoped down to the mailbox, the folder and the operations the workflow actually performs.
Some line-of-business systems only offer a user login. In that case create a deliberate functional account, keep its credentials in the company password manager, and name it so anyone reading the directory can tell what it is. One extra license a month is cheaper than two days of stalled order processing.
Twenty minutes to find out where you stand
Open the connections list in your automation platform. Every entry shows who authorized it. Flag each one tied to a personal name, then ask which process stops when that person leaves, and whether they are still with you at all.
Check where the output lands. Personal drive or shared structure? Check the sending address while you are there. If automated mail goes out under an individual, customer replies arrive in a mailbox that disappears with the next departure.
Watch how repairs happen, too. When a connection breaks, the quickest way back is for whoever is closest to sign in again. The workflow recovers within the hour and the dependency has simply moved to a new name. We have seen automations pass through three people that way, each of them convinced they were fixing it. Write down that connections get rebuilt through the service account and nothing else.
Then add one line to the IT offboarding checklist asking which automations and connections run under the account being closed. It costs nothing and it is the only reason this does not happen to you twice.
The last audit we ran turned up six connections on two names, one of whom had left three months earlier. The workflow behind them had been failing ever since. Nobody had escalated it, because the team had gone back to doing the work by hand and assumed that was how it was meant to be.