Whose accounts does your automation actually run on?
There is a question almost nobody asks before commissioning an automation, and it decides more about the lifespan of that automation than the platform, the budget or the developer does.
Which account does it log in as?
The answer, most of the time, is: somebody's personal one. The office manager's email. The founder's Google account. A shared password that three people know and nobody has changed since 2023. The automation works perfectly, right up until that account changes in some ordinary way, and then it stops - usually quietly, and usually at the worst moment.
Why does this break so reliably?
Because personal accounts are supposed to change. That is what makes them personal.
A password rotation, a security policy that switches on two-factor authentication, a laptop replacement, an OAuth token that expires after ninety days, a person leaving and their account being suspended on their last day - every one of these is normal IT hygiene, and every one of them takes down an automation that was quietly depending on that identity.
The failure is worse than an outright error, because it does not usually look like one. The workflow still runs. It authenticates, fails, and moves on. On some platforms that shows as a red run in a log nobody reads. On others it shows as a success, because the step that failed was configured to continue on error. This is the same category of problem as automations that fail silently, with the added indignity that the cause is administrative rather than technical.
What are the actual options?
There are three, and they suit different situations.
| Personal account | Service account | Client's own platform instance | |
|---|---|---|---|
| Who owns the login | an individual | the business | the client |
| Survives that person leaving | no | yes | yes |
| Cost | none | usually a licence seat | full platform subscription |
| Audit trail says | that person did it | the automation did it | the automation did it |
| Setting it up | already done | half an hour | an account and a card |
A service account is a login that belongs to the business rather than to a
human: automation@yourcompany.com, with its own licence, its own password in
the company vault, and no phone attached to it that leaves the building on
Friday. Google, Microsoft and most serious platforms support this properly. It
costs a seat, and the seat is the cheapest insurance in this article.
The client's own instance matters when an agency or a contractor builds the automation. The rule to insist on is that the client buys their own account and the contractor gets a seat in it, never the other way round. That is not licensing pedantry: it decides who still has a working business if the relationship ends.
The audit-trail problem nobody mentions
When an automation runs on a person's account, every action it takes is recorded as that person's action.
The invoices were approved by Sarah. The records were edited by Sarah. The emails were sent by Sarah. Sarah was on holiday, and the automation was doing its job perfectly - but the log does not know that, and neither will anyone reading it a year from now during a dispute, an audit or an insurance claim.
For a business that keeps financial records, this is the strongest argument for a service account, ahead of the reliability one. You want the log to be able to say the system did this and a person did this, because those two statements carry completely different weight when something goes wrong.
Two-factor authentication and the automation problem
This is the friction point where most small businesses give up and do the wrong thing.
Two-factor authentication protects an account by requiring something beyond the password - a code from an app, a text message, a hardware key. It is not optional any more; insurers ask about it, and platforms increasingly enforce it. And an automation cannot read a code out of somebody's phone.
The wrong resolutions are common and worth naming, because they all look reasonable in the moment: turning 2FA off for the account the automation uses, routing the codes to a shared inbox everybody can read, or - the one that shows up in automation forums regularly - building a workflow whose job is to intercept the verification code and feed it back in. Each of these takes a control that exists for a reason and hollows it out.
The right resolution is to stop using a human login for a machine job. Proper integrations do not need 2FA at all, because they do not log in as a person:
- API keys and OAuth apps. Issued to an application, revocable individually, with no phone involved. This is what platforms want you to use.
- Service accounts with key-based authentication, for the Google and Microsoft side of the world.
- Scoped tokens that can read what they need and nothing else.
If a system you depend on offers none of these and the only route in is a human login, that is a real finding about that system. It belongs in the decision about whether to automate around it at all.
Least privilege, in the version that fits a small business
The formal principle says every credential should have the minimum access it needs. In a company of six people that can sound like security theatre. It is not - it is what turns a bad day into a survivable one.
A practical version, in the order worth doing it:
- One credential per integration, not one shared login used everywhere. A compromised or expired credential should take down one thing, not everything.
- Read-only wherever writing is not needed. A reporting automation has no business holding a token that can delete records.
- Write it down. A one-page list of which credential exists, what it can reach, who owns it and where the secret lives. This is the document nobody has, and the first thing anyone needs in an incident.
- Revoke on the way out. Offboarding checklists cover email and payroll and almost never cover the eleven integrations connected to that person's account.
What to check on the automations you already have
Twenty minutes, and you can do it without a developer:
- Open each automation and look at the connected accounts. Whose name is on them?
- Ask what happens to each one when that person's password next changes.
- Check whether anything critical runs under an account belonging to someone who has left.
- Find out where the credentials are actually stored. If the answer is a spreadsheet or a message thread, that is the finding.
- Confirm that a failed authentication produces an alert somebody receives - not a red entry in a log nobody opens.
The last one is the difference between finding out on Tuesday and finding out when a customer tells you.
What this means when you are commissioning work
Ask the question before the build, not after. Whose account will this run on, and what happens when that account changes? A developer who has an answer ready has done this before. A developer who says "we will just use your login for now" is building you something with an expiry date they have not told you about.
The cost of doing it properly is a licence seat and half an hour. The cost of not doing it is discovering, during someone's notice period, which parts of the business were quietly running on their Google account - and having no list to work from.
That inventory is one of the things the process audit produces: $299, three business days, a written map of what runs where, on whose access, and what breaks when it changes.