Who Owns Your Automation When the Colleague or the Contractor Leaves

Two questions decide whether an automation belongs to you or merely runs at your company. First: does it keep running when the person who set it up leaves? Second: can you switch providers without having the process built a second time?

In many projects neither question is asked. They still get answered, only months later and without your involvement.

Whoever grants the connection owns it

When a connection to a mailbox, a drive or a line-of-business application is created, a sign-in window opens. The person who enters their credentials there and confirms is the one granting access. In return the automation platform receives a token bound to that single account and operating with its permissions.

That token does not outlive the account. When the account is disabled on the last working day, access expires, with modern sign-in policies within minutes. And far less than a resignation is needed: a password change after a phishing suspicion is enough, as is resetting two-factor authentication when somebody loses a company phone. Both happen at short notice and without asking the department.

That is the awkward punchline: a clean offboarding, the kind every auditor wants to see, switches your automation off.

There is also the question of who owns the output. Whatever a process writes into a user's personal storage area belongs to that account. Once the user is deleted after the retention window, the files go with them unless somebody transferred ownership first. For shipping documents or accounting records subject to statutory retention, that is more than an annoyance.

The failure shows up weeks after the last working day

The day of deactivation is rarely the day anyone notices. Many processes run weekly or monthly, others only trigger when a particular case occurs. The error appears at the next run, by which time the staff change is long since filed away.

It also appears quietly. The target system refuses access, the log shows one aborted run, nothing more. Without an active notification nobody sees it. In the connection overview some platforms still display a green tick, because the status is only refreshed on the next access attempt.

And nobody feels responsible. IT works through its offboarding list: collect the device, disable the account, release the licence. That list does not say which processes depend on the account, because that knowledge sits in the department. The department, in turn, has no reason to suspect that a resignation has technical consequences.

An automation needs an identity that cannot resign

A better offboarding list only helps so far. Operation belongs under an identity that does not personally belong to anyone.

In the common office environments that means a registered application or a service account with its own permissions. It usually costs no extra licence, its rights can be narrowed to individual mailboxes and folders, and no staff change revokes them. For sending and receiving, use a shared mailbox or a group address with several people behind it. Generated files belong in shared storage, not in a user's personal area, otherwise the ownership problem has only been moved.

Do not give that identity more rights than it needs. Service accounts with sweeping administrative permissions usually exist because that raised the fewest questions during setup. Yet an access path with no expiry date and no person behind it is precisely the one that should be cut narrowly: one mailbox, one folder, the rights the process actually uses.

Some industry applications do not offer this route and only know the interactive sign-in dialog. In that case set up a deliberate functional user whose credentials live in the company password manager and which is recognisable as such in the directory. That costs one licence per month. Two days of standstill in order processing cost more.

The second dependency is called the contractor

The same question arises one level up, and there it is asked far less often. In whose name does the account with the automation platform run? Who pays the licence? Do the credentials for the connected systems sit with you or only with the provider? Is there a description of the process that a different provider could pick up?

A subscription model sharpens all of this. As long as you pay, the automation runs. When the contract ends, access ends, and what you paid in the years before was rent. That is not wrong in principle, it simply has to add up over the term and you have to know it. It gets uncomfortable where a low entry price makes leaving expensive.

What to settle before signing

Put four points in writing before anything is built.

First, all accounts and licences are in the company's name, not a person's and not the provider's. The provider works as an invited user inside your account.

Second, connections are established exclusively through service accounts. That belongs in the agreement explicitly, because otherwise the fastest fix after a broken connection is always the same: whoever is nearest signs in again. That is how an automation travels through three colleagues without the problem ever being solved.

Third, sign-off includes documentation and an export of the process, stored on your side. Without those two, switching providers means rebuilding.

Fourth, one line on IT's offboarding list: check which automations and connections run on this account. Added once, the subject does not come back.

Taking stock takes half an hour

If processes are already running, open the list of connections in your platform. Next to each one is the name of whoever authorised it. Mark everything running on a personal name and check two things: is that person still with the company, and which process stops when they leave? Then look at where generated files are written and under which address the automation sends mail outward.

Everything pointing at a personal name is an unpaid bill that comes due with the next staff change. Settling it usually costs an afternoon. Leaving it costs the day nobody expects.

Sophera Consulting sets automations up on the client's own service accounts from the start and hands over credentials, documentation and an export at a fixed price, with no subscription. The entry point is free in the automation check.