What a CRM integration audit actually checks

Most broken integrations were not built badly. They were built on top of data that was already inconsistent, against an API nobody had read carefully, with no plan for what happens when a sync fails at 2am. An audit is how you find all of that before you spend a sprint wiring things together.

When someone books an audit with me, I am not selling a 40-page PDF. I am answering one question: if we connect these systems, what will actually break, and what will it cost to do it properly? Here is what I look at to get there.

1. The shape of the data on both sides

The first thing I map is what each system thinks a "customer" is. It sounds trivial. It almost never is.

• Does your CRM key contacts on email, on a record ID, or on a fuzzy name match?
• Are companies first-class records, or just a text field on the contact?
• What is mandatory on one side that is optional on the other?
• Where do duplicates already live, and how many are there?

If one system allows two contacts with the same email and the other does not, that is not an edge case you will hit eventually — it is a migration you have to plan for on day one.

2. The real API, not the marketing page

Every platform's integrations page promises everything is possible. The audit is where I read the actual API docs and find the parts that are not.

• Rate limits. How many calls per minute, per day, per token? A nightly sync of 50,000 records against a 100-calls-per-minute limit is a math problem you want to solve before you promise a go-live date.
• What is actually writable. Plenty of fields you can read you cannot write back. Computed fields, system fields, and picklists with locked values all quietly fail or get silently dropped.
• Pagination and change-tracking. Can you ask "what changed since yesterday," or are you forced to pull everything and diff it yourself? That single answer decides whether your sync is cheap or expensive to run.

3. Where the trigger actually comes from

"When a deal closes, update billing" is a sentence, not a design. The audit turns it into a real event source.

The most common failure I see is a sync triggered by a button a human has to remember to click. If the process depends on someone not forgetting, it is not automated — it is just delayed.

So I check: is there a webhook for this event? A workflow rule that can fire one? A reliable polling window? And critically — does the event fire once, or can it fire three times for the same change and create three invoices?

4. The failure path

This is the part that separates a demo from production, and the part most quotes skip entirely.

• What happens when the target system is down for ten minutes?
• Where does a rejected record go — a dead-letter log, an email to you, or nowhere?
• Can the sync be safely re-run without creating duplicates? (This is called idempotency, and it is the single most valuable property an integration can have.)
• Who finds out when something silently stops?

An integration with no failure path is a liability with a countdown timer. I would rather tell you that during an audit than after a launch.

5. Access, security, and ownership

Finally, the unglamorous checklist that keeps you out of trouble later:

• Scoped API tokens with the minimum permissions, not an admin key pasted into a config because it was faster.
• A record of which tokens exist, where they live, and when they expire.
• A clear answer to "if NextFlow Builder disappears tomorrow, can your team run and change this?" — because you should own every line of it.

What you walk away with

At the end of an audit you get a plain map of your stack, the specific risks ranked by what they will actually cost, and a 30-day roadmap with one quick win you can ship immediately. No lock-in, no dependency on me to keep it running.

If two of your systems are not talking and you are not sure why, that is exactly what the AI Automation Audit is for. Send me a short brief and I will tell you whether it is worth fixing — honestly, even if the answer is "this one is simpler than you think."