Use a dedicated service account with a named owner for any automation that runs unattended. A personal login ties the job to one person's access, so it breaks when they leave or reset a password and usually carries far more permission than the job needs.
What a connection really is
In a low-code tool, a connection is a saved credential for a connector. Microsoft's documentation puts it plainly: a connection represents a saved credential and is stored within the environment that hosts the app or flow. Whoever signs in when the connection is created decides whose access the automation has.
If that person is a senior admin, the automation inherits an admin's reach, even if all it does is copy rows to a sheet.
Comparing the options
| Property | Personal login | Dedicated service account |
|---|---|---|
| Permissions | Everything that person can do | Only what you grant the account |
| When the owner leaves | Job fails or runs on a dormant account | Unaffected, owner is reassigned |
| Password or token reset | Breaks the job | Planned and documented |
| Audit trail | Actions look like a person acted | Actions are clearly the automation |
| MFA | Person's device | Needs a plan, such as an app registration or key |
| Review | Easy to forget | One account to review |
Setting up a service account well
- Create the account with a name that says what it does, such as an integration name plus function, not a person's name.
- Grant the minimum role. If the job only reads one folder, share only that folder.
- Record two owners, a primary and a backup, and their team.
- Store its credentials in a secrets manager. Do not paste them into tool notes.
- Use the strongest sign-in method the service supports. Where an app registration or key replaces a password, prefer that.
- Set a review date. Remove the account when the automation is retired.
- Alert on sign-ins from places and times the job never uses.
When a personal connection is acceptable
- A one-off personal helper that touches only that person's own data.
- A prototype in a sandbox, with a plan to rebuild before production.
Even then, record it. Prototypes have a habit of becoming production.
Offboarding check
On a departure, search your automation platform for connections created by that person, and for flows they own. Reassign or rebuild each one before disabling the account, or you will find out which ones mattered when they fail. See also the SaaS offboarding checklist for a departing employee.
Quick check
Is a shared mailbox login a service account?
Not really. A shared login used by several people has no single owner and a weak audit trail. Create a distinct account for the automation.
Do service accounts need MFA?
They need strong authentication, but the method differs. Use keys, certificates or app registrations where the platform supports them, and restrict where they can sign in from.
Safeguard's agent identity and asset discovery features follow the same idea of named, scoped non-human identities. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
