Your Integration Is Connected to a Person's Login — and That's Why It Broke

A nonprofit’s online giving had been flowing into their CRM for months without anyone thinking about it. Then it stopped. No code changed, no settings were touched, no error appeared. Gifts kept coming in through the website; they simply stopped arriving in the database. For about four weeks staff hand-keyed every donation, assuming that was just the job, until someone asked why the “automatic” sync wasn’t automatic anymore.

The cause: a staff member had turned on two-factor authentication for their own account over a weekend. That account was the one the integration had been quietly using to log in.

Why a personal login is a fault line

An integration needs one thing above all: a stable credential. A person’s login is the opposite of stable. It carries every security event that happens to that human:

• They enable MFA, and the integration’s silent login now expects a code nobody types.
• They rotate or reset a password, and the saved credential is dead.
• They leave, and IT deactivates the account — taking the sync with it.
• Their permissions get tightened, or a session-security policy changes, and the integration loses access to exactly the records it was reading.

None of those are mistakes. They’re normal account hygiene. The mistake was wiring infrastructure to an identity that was always going to change.

Why it’s worse than an ordinary outage

This kind of break is invisible. The platform on the other end often still shows “Connected,” because it’s holding a cached token and only finds out it’s dead the next time it tries to act. Nothing turns red. No alert fires. The data just quietly stops — and because the records that did sync are still sitting there, a quick look says everything’s fine.

You don’t discover the gap until someone reconciles totals weeks later, and by then you’re paying for it in manual re-entry, missing history, and the slow erosion of trust in “the system.”

The fix: give the integration its own identity

Connect integrations as a dedicated, non-human account, scoped to only what they need:

• In Salesforce, that’s an integration user — and you no longer have to burn a paid seat for it; Salesforce includes free integration-user licenses for exactly this. Grant access with a permission set, set it to skip MFA via policy (it’s a service account, not a person at a keyboard), and document what it’s for.
• On the other side — the giving platform, the form tool, the data pipeline — authenticate with a service or owner-level token, not a staffer’s personal account, so removing a team member never severs the connection.
• Least privilege. The account should be able to do its one job and nothing more. That limits the blast radius if its credential ever leaks.

How to find these landmines in your stack

Walk through each integration you have and ask one question: connected as whom? Open the connection settings and look at the account name. If it’s a real person — especially someone in finance, or someone who might leave — that integration is a future outage with a date you can’t predict. Move it to a dedicated identity now, while it’s working, instead of during the scramble after it breaks.

The deeper lesson

Integrations are infrastructure, and infrastructure shouldn’t ride on a person. People enable security features, change roles, and move on — that’s what they’re supposed to do. When you let a sync depend on one human’s login, you’ve quietly made that person a single point of failure for a system they may not even know they’re holding up. Give the machine its own keys.

---

I’m Chris Moore — an independent consultant in Henderson, NV. I work with small nonprofits on Salesforce cleanup and the integrations that feed it, including pro-bono engagements through Catchafire and Taproot. If a sync in your stack broke and “nobody changed anything,” get in touch.