Service accounts for automations: how a small firm sets one up

Most automations in a small firm run on the login of whoever built them. The intake Zap uses the office manager's CRM connection, the invoicing flow runs under a partner's Microsoft 365 account, and nobody notices until that person changes their password, loses their phone or leaves.

The direct answer: yes, a firm with automations that touch client records, billing or shared work should run them on a service account for automations, a login that belongs to the firm rather than a person. Set it up with an address on your own domain, the password in the firm's password manager, multi-factor authentication kept on, two named people who can recover it, and a written list of everything connected to it. In Power Automate, check the licensing first, because one shared Premium license is not allowed.

Why a service account for automations beats one person's login

Every automation logs in to your apps through a saved connection. When the person behind that connection resets their password, loses the device that holds their second factor, or has their license removed, the connection stops working and so does every automation using it. Often nothing visible happens for days: forms still submit, but records stop arriving.

The departure case is the most painful, and we cover it in detail in what happens to automations when an employee leaves. A firm-owned account removes most of that risk before it happens, because the login outlives any one person's job.

Service account, shared connection or service principal

Three terms come up, and they are not the same thing.

Microsoft describes a service principal as "a non-human security identity" that can own and manage resources, including flows.

Do you need one?

A dedicated service account for automations is worth the effort when:

• the automation touches client records, matters, invoices or payments;
• several people depend on its output;
• it would be noticed within a day if it stopped;
• it connects to an app where per-person access already changes often.

It is probably not worth it for a personal reminder Zap or a flow that copies files for one person. Leave those on the individual's account and accept that they go when the person goes.

One check before you start: ask your IT provider or whoever manages your Microsoft 365 or Google Workspace. Some firms' security policies forbid non-personal logins, or require them to be set up in a particular way. A shared login for integrations also uses a paid seat in some apps, so price that in.

Setting up a Power Automate service account

Start with licensing, because this is where firms get caught. Microsoft's Power Automate licensing FAQ, updated September 2026, sets out the rules for flows running under a shared service account as owner:

• Standard connectors only. No extra license is needed; Power Automate is covered for work accounts in the tenant.
• Premium connectors or features. If a small, fixed set of people share the account, license those users and the service account. If many people share it, assign a Process license to the flow instead.
• One Premium license on a shared account. Microsoft is explicit: assigning a single Premium license to a service account that many users share is multiplexing, and the flow is not compliant.

Multiplexing in Power Automate means one license standing in for many people. If you are unsure which side of the line a flow sits on, ask your Microsoft licensing partner before you move it.

Moving Power Automate flows to the service account

1. Make sure each important flow is one of the solution-aware flows. Microsoft's guide to changing a flow's owner says only solution-aware flows can change owner in place.
2. In the flow's Details, change the primary owner to the service account. The old and new owners become co-owners.
3. Recreate or share the connections under the service account, and test.
4. Note that scheduled and automated flows switch to the new owner's license, which Microsoft says can take up to seven days unless you edit and save the flow.

Microsoft's own note in the licensing FAQ goes further: it recommends a Microsoft Entra service principal as flow owner rather than a shared service account, because shared credentials are a security risk and make it hard to see who changed a flow. A service principal Power Automate setup needs an application user, the connections shared with it, and attention to request limits, since it has no user license. That is usually a job for your IT provider; for many small firms a well-run service account is the practical middle ground.

Setting it up in Zapier and Make

Zapier

On Team and Enterprise plans, Zapier shared app connections work like this, per Zapier's help article on sharing connections, as documented in October 2026:

• Connections are private by default; only the person who made them can use them.
• You can share a connection with specific users, or with everyone on the account (Enterprise can also share with teams).
• The Zap owner needs access to every connection in a Zap before turning it on.
• If sharing is revoked, a published Zap that relies on that connection pauses.

The cleanest pattern: sign in to each app as the service account, create the connection from that login, and share it with the people who build Zaps. Zapier's ownership article also explains how Zaps transfer to a chosen owner when a member is removed, which is your safety net.

Make

In Make, connections belong to a team, and Make's teams help page says every item belongs to only one team and cannot be moved to another. Roles range from Team Admin to read-only Team Monitoring, and below the Teams plan you get one team with no role management. So create the team first, then create connections in it while signed in to each app as the service account.

Who holds the keys

The account is only safer than a personal login if it is run properly:

• Address on your domain. automations@yourfirm.com, never a personal webmail address someone set up in a hurry.
• Password in the firm's password manager, in a shared vault limited to the people who need it. Never sent by email or chat.
• MFA kept on. Register the second factor so at least two named people can approve a sign-in or recover the account. Turning MFA off to avoid prompts trades a small annoyance for a large risk.
• Least privilege. Give the account access only to the apps, folders and scopes the automations need. It does not need to be an admin everywhere.
• A named owner and a backup owner, written down.
• A one-page register of every connection on the account: app, what uses it, when it was connected, when it expires.

Then set up failure alerts so a broken connection on the account reaches a person the same day, not the following week.

A worked example

Illustrative only: a 20 person accounting firm has 12 Zaps and 4 Power Automate flows, built by three people over two years.

1. Inventory. List every Zap and flow, its owner and each connection it uses. In this example, 9 of the 16 depend on one partner's logins.
2. Create the service account for automations with IT: automations@ on the firm's domain, MFA registered to two people, stored in the password manager.
3. Check licensing. Two flows use premium connectors, so the firm confirms the licensing with its Microsoft partner before moving them.
4. Reconnect one connection at a time. Create the CRM connection as the service account, switch each Zap that used the old one, run a test, then move to the next app.
5. Retire personal connections once every automation has run successfully on the new ones.
6. Write the register and agree who reviews it each quarter.

How Flow Mesh helps

During an integration or workflow automation project we set up firm-owned accounts and shared connections inside your own tenant and apps, and leave the written register behind. Every engagement starts with a first call and a stack audit, scoped in writing, that gives each tool a verdict: keep, configure, consolidate or replace.

Key takeaways

• Run automations that touch clients, billing or shared work on a firm-owned account, not one person's login.
• Keep MFA on, store the password in the firm's password manager, and name two people who can recover the account.
• In Power Automate, one Premium license on a widely shared account is multiplexing; license the users or use a Process license, and consider a service principal.
• In Zapier, create connections as the service account and share them; in Make, create them inside the right team.
• Keep a written register of every connection on the account and review it regularly.