Before You Buy an Integration, Check What's Already Installed

A nonprofit asked me to build an integration to get their survey responses into Salesforce. Standard request. So I went looking for the right tool to build it with — and found the integration already installed. Not only installed: already pointed at the right form, already mapping fields to contacts, set up by someone months earlier. It had processed a grand total of three records, thrown a few errors, and gone quiet. Everyone who currently worked there had concluded the org simply didn’t have that capability.

This is one of the most common things I find, and it’s almost never on the list of things a team thinks they need help with.

Why orgs end up owning integrations they’ve forgotten

• A managed package gets installed during a trial or a vendor demo, and nobody uninstalls it when the trial ends.
• A previous admin or volunteer set it up partway and left before finishing — especially common with rotating, pro-bono, or contract help.
• It “didn’t work,” so the team stopped using it — without anyone diagnosing why. The tool is fine; the configuration was never completed.
• It fails silently, so it drops off everyone’s radar, and institutional memory quietly forgets it was ever there.

A year later, someone scopes a project — and budget — to do the exact thing the org already installed a tool to do.

What it actually costs you

The obvious cost is buying or building a second tool to duplicate one you already have. But the quieter cost is worse: a half-configured integration isn’t dormant, it’s misbehaving. The one I found was creating duplicate contacts every time someone filled out the form. Abandoned connectors throw errors into logs no one reads, hold open connections under a departed employee’s login, and slowly corrupt the data around them. “We don’t use that” and “that is damaging our database” are frequently the same sentence.

How to take inventory before you build

Spend an hour here before you spend a dollar anywhere else:

1. List installed packages. In Salesforce, Setup → Installed Packages. Read every name, not just the ones you recognize. Do the same on the other platforms in your stack.
2. Look for orphaned configuration. Custom objects, field mappings, connected apps, named credentials, integration users, scheduled jobs — the fingerprints of a setup someone started.
3. Read the error log the package keeps. Most integrations log their own failures somewhere. A pile of errors that stops on a certain date tells you when it died and often why.
4. Ask “connected as whom?” If a sync authenticates as a person who left, that’s both your break and your fix. (More on that here.)
5. Find out who built it and whether they’re still around. Deactivated users and abandoned draft automations are the trail of half-finished work.

Then decide: finish, replace, or remove

Once you can see what’s really there, the choice is clear-eyed instead of default. Usually finishing what’s installed is faster and cheaper than a greenfield build — the hard parts (license, install, base mapping) are done. Sometimes the installed tool is genuinely wrong and the honest move is to remove it cleanly so it stops doing harm. Either beats buying a third thing to sit alongside two that don’t work.

The deeper lesson

The most cost-effective integration project is often not a build — it’s an audit. Before you buy or commission anything, take a full inventory of what’s already in your systems. In my experience, “we don’t have a way to do that” turns out, more often than not, to mean “we have a way to do that, and it’s been broken so long that everyone forgot we own it.”

---

I’m Chris Moore — an independent consultant in Henderson, NV. I help small nonprofits get more out of the systems they already pay for — Salesforce and the integrations around it — including pro-bono engagements through Catchafire and Taproot. If you suspect you’re about to rebuild something you already own, get in touch.