Your Automation Logs In With Someone's Password. What Happens When It Changes?

The break nobody notices

Most automations don't fail because the logic is wrong. They fail because the thing they log in with stops working. Your workflow reads a shared mailbox, writes to your accounting system, or calls a voice service, and every one of those connections rests on a saved password, an API key, or an account someone connected once and forgot about.

Here's a pattern we've seen on a real project. A shared mailbox asked a staff member to reset its password. They did, which was the right thing to do. The automation that read that mailbox lost its connection the moment the password changed, and an outreach workflow quietly stopped sending. Reconnecting the credential in the workflow tool took a couple of minutes. Noticing that anything was wrong took days.

That gap is the real cost. So treat a password reset, or any "please sign in again" prompt, as an automation event and not just an IT chore.

Keep a list of every credential your automations use

You can't protect what you can't find. Keep a simple list, a spreadsheet is fine, with one row per saved credential. It only needs a few columns:

• Which system it connects to, and which account inside that system it belongs to.
• Which workflows use it, so you know what stops when it breaks.
• Who can reconnect it, meaning someone who actually has the login.
• When it expires, if it has an expiry date at all.
• Where the secret itself is stored (a password manager or the workflow tool's encrypted credential store, never a document or chat message).

Use shared accounts and name things consistently

Whenever you can, connect automations through a shared or service account rather than one person's own login. If the workflow runs on an employee's personal account, it breaks the day they change their password, lose access, or leave, and nobody else can fix it without their help.

Name credentials the same way every time: who it's for, then the service, then the purpose. Something like "Team name, accounting system, read only" or "Team name, voice service, outbound calls". When a password changes, you can search that name and find every workflow that needs attention instead of guessing.

One more trap: make sure the key comes from the right account. An API key from an empty account, or from a different account than the one that owns the phone number, the data or the billing, looks perfectly valid and still won't work. Before you wire a key in, confirm it belongs to the account that actually owns the resources the automation needs.

Choose expiry dates on purpose

Many services ask you to pick how long a key lasts: 30 days, a year, or never. People tend to click whatever is selected and move on. Make it a decision instead.

A short expiry is safer, because a leaked key stops working on its own. But it guarantees your automation will break on a known date unless someone renews it first. If you choose a short expiry, put the renewal on a named person's calendar and set a reminder a week before it lapses.

If you choose a key that never expires, make up for it in other ways. Limit what the key is allowed to do, for example read only, or one mailbox instead of all of them, and replace it on a schedule you pick, such as every quarter, so an old key doesn't live forever.

Make password resets visible to the person who owns the workflow

The people who reset passwords usually aren't the people who built the automation. They don't know a mailbox is wired into anything. So give them one simple rule: if you reset the password on a shared account, or a system asks you to re-authorize a connection, post it in a named channel right away.

The workflow owner watches that channel and reconnects the credential the same day. It costs the team one message, and it turns a silent multi-day outage into a two-minute fix.

Alert on login failures, then catch up what was missed

A failed login is a different kind of error from bad data or a timeout, and it should get its own alert. When an automation can't authenticate, it can't do anything at all, so send that alert to the person who can reconnect it, and say which credential failed and which workflows depend on it.

Reconnecting isn't the end of the job. Anything that should have run during the gap didn't. Check what was missed (emails that weren't read, records that weren't written, messages that weren't sent) and rerun or catch them up deliberately. Don't assume the backlog will clear itself, and don't blindly rerun everything either, or you may send the same thing twice.

A short checklist

Before you call an automation finished, run through this:

• Every credential it uses is on your list, with its system, account, workflows, owner and expiry date.
• Each connection uses a shared or service account, not one person's own login, wherever that's possible.
• Credential names follow one pattern you can search.
• Every API key came from the account that owns the data, number or billing it needs.
• Short expiry dates have a renewal reminder on a named person's calendar.
• Keys that never expire are limited in what they can do and replaced on a schedule.
• Your team knows to post in one channel whenever they reset a shared password or see a re-authorize prompt.
• Login failures trigger their own alert, and you have a plan to catch up missed work after reconnecting.