Admin rights will not let you fix it: who can actually repair an automation

Something breaks on a Tuesday. The person who can see it is not the person who can fix it, and giving them a more senior role does not help. This surprises owners, because in every other system it does.

The reason is that automation platforms hand out two different kinds of permission, and only one of them looks like an org chart.

Permission on the workflow, permission on the connection

A workflow is one object. The account it uses to reach your CRM, your inbox or your payment provider is another. Rights over the first do not carry to the second.

Zapier's documentation on roles is explicit about the consequence: only the owner of a private connected account can create and edit steps using that account. Members, admins, super admins and even owners who have access to the workflow have view permissions on that step and nothing more.

So the most senior person in your account can open the broken automation, read every step, understand exactly what is wrong — and be unable to change the step, because the connection it runs on belongs privately to somebody else.

This is not a bug. It is the platform refusing to let one person operate another person's connected accounts, which is a reasonable thing to refuse. It just produces an outcome that feels absurd on the morning you meet it.

What seniority does and does not buy

To be fair to the roles, they are not decorative. The same documentation notes that super admins have broad powers — viewing, sharing, deleting and exporting members' content, both public and private — and that account owners, super admins and admins decide which apps the team may connect to at all.

That is real control over the account. It is control over the container, not over the credentials inside it.

There is a second consequence in the sharing documentation that catches people during handovers: when a workflow is turned on or published, its owner must have access to every connection it uses, and if a connection has not been shared with them, they cannot turn it on. Transfer a workflow to a colleague without sharing the connections underneath, and they now own something they cannot switch on.

Why this reliably happens in small businesses

Nobody designs this arrangement. It accumulates.

The first automations get built by whoever was keen, using their own logins, because that was the fastest way to get something working. Later ones are built by someone else, the same way. Nobody shares connections, because sharing is not required to build — only to hand over or repair.

Then somebody leaves, or goes on holiday, or moves to another part of the business, and the arrangement becomes visible for the first time. Usually while something is broken.

The pattern to watch for is a business where each automation has exactly one person who can repair it, and that person is different for each automation. That is not a team with distributed knowledge. It is several single points of failure wearing a trench coat.

What to arrange, before Tuesday

Find out who owns each connection. Not each workflow — each connection. In most small businesses this has never been written down, and writing it down takes an hour and answers most of this article.

Share the connections that matter. Where the platform supports it, a shared connection means more than one person can edit steps that use it. This is the single change that converts "only Anna can fix it" into "someone can fix it".

Use accounts that belong to the business. A connection made through ops@yourcompany.com survives a person leaving; one made through a personal login does not. This costs nothing at setup and is expensive to retrofit.

Make sure two people can do everything critical. Not everyone, and not formally — just more than one. The test is simple: for each automation that would hurt to lose for a day, name two people who could repair it. Any answer with one name is a plan to be unavailable at the wrong moment.

Check what the tier allows. Sharing and role features often belong to team plans. If you are on a personal plan, the honest position is that this problem is not solvable by configuration, and you should know that rather than assume otherwise.

The awkward middle: contractors

An outside builder makes this sharper, because their connections are theirs by definition.

Two things worth deciding at the start rather than the end. Whose accounts the automations connect through — ideally yours, with credentials you hold, even while they do the work. And what "finished" means in terms of access: not only that the workflow runs, but that somebody in your business can edit every step of it after the contractor has gone.

That second point is easy to agree at the outset and awkward to raise afterwards, which is a good reason to raise it at the outset.

When permissions are the wrong tool

For a business with a few automations and two or three people, the arrangements above are enough, and they are mostly bookkeeping.

It changes when automations run on connections nobody should hold personally — the payment provider, the accounting system, anything where an individual's access is itself a risk. Then the question is not who to share with but whether the automation should be running on a person's login at all, rather than through credentials issued to the business for that purpose.

Sorting out which of your automations are attached to people and which are attached to the business is one of the things a process audit covers: $299, three business days, and a list of who can currently repair what.

Related: the person who built your automations has gone. What now? covers what these same rules mean once somebody has actually left.