What to Do When the Person Running Your Integrations Leaves

When a key employee moves on, most of their work is visible. Emails get forwarded, projects get reassigned, clients get a transition call. But integrations are different. They run quietly in the background, doing work nobody thinks about until something stops working.

If you've just stepped into a role where someone else built and/or managed the integrations, this is the article that gets you up to speed.

What you actually inherited

An integration connects two or more software systems so they can share data automatically. In most midsize organizations, that looks like:

• Customer data flowing from your CRM into your accounting software
• Invoices syncing between platforms without anyone manually exporting spreadsheets
• Membership records, donations, project data, or payroll information moving between systems on a schedule

The person who set this up probably built something that saves your team hours of manual work every week. That's what you inherited. And if it's running well, you might not even notice it yet.

Why this matters even when nothing seems wrong

Integrations don't fail with a flashing red light. They tend to fail quietly: a sync stops running, data gets duplicated, a field that used to populate automatically is now blank. By the time someone notices, the problem has been compounding for days or weeks.

The downstream effects add up fast. Finance is running reports on stale data. Sales working from a CRM that stopped updating. Membership records a month behind.

None of this is your fault, and all of it is fixable. But you do need to know what you have.

Five things to find out right now

If you can answer these five questions, you're in good shape.

1. What systems are connected? Get a list, even a rough one. CRM to ERP, donations platform to accounting software, whatever it is. You need the map.
   
   
2. What triggers the integration? Does it run on a schedule (every night at midnight)? Does it fire when a record is updated? Knowing this tells you what to watch.
   
   
3. Who owns the credentials? Most integrations authenticate with API keys or service accounts. If the person who left took those credentials with them, or they're tied to a personal account, that's your first priority.
   
   
4. What's documented? Check for setup docs, runbooks, or any notes from the original build. Even a one-pager is useful. If nothing exists, your integration provider can help you recreate it.
   
   
5. Who do you call when something breaks? If your organization worked with an integration partner to build this, that relationship doesn't walk out the door when your internal person does. Find that contact and introduce yourself.

Making this yours

Your job isn't to understand every line of logic or become the integration expert overnight. It's to know enough to keep things running, recognize when something's off, and know who to call.

Sometimes what you inherit isn't a well-oiled machine. It's a patchwork held together with good intentions and a prayer. That's a different conversation, but it's still a solvable one.

A good integration partner will help you get there. Whether you inherited something solid or something that's already showing cracks, they can help you figure out where things stand and what to do next.

Not sure what you've got? Let's talk.