The Mid-Market Guide to Integration Health Checks

Why green sync indicators lie

A green sync indicator means the connection is alive. It does not mean the data is complete, mapped correctly, or handled when exceptions occur. I have seen integrations show green while sending incomplete customer records, dropping branch codes, duplicating invoices, and creating orphan records that no one discovers until month-end.

The danger of green indicators is complacency. Operations trusts the light. Leadership trusts the dashboard. And the real problems accumulate silently until they surface as a crisis. One company I worked with had a green ServiceTitan-to-QuickBooks sync for six months while it created over four hundred duplicate customers. No one noticed until reconciliation.

Green indicators measure connectivity, not correctness. They tell you the pipe is open. They do not tell you what is flowing through it, whether it is complete, or whether it arrives in the right shape. That requires deliberate checking. Think of it like a water main: the pressure gauge shows the pipe is pressurized, but it does not tell you whether the water is clean.

The five checks every integration needs

Every integration should pass these five checks. If any fail, the integration is partially broken and creating operational drag. These checks can be performed by anyone with access to both systems and a checklist.

• Data completeness: Are all expected records transferred? Sample 50 recent records and compare source to destination. Look for missing fields, truncated values, or skipped records. A common failure is that the sync transfers customer name and address but drops custom fields or notes.
• Field mapping accuracy: Does each field in the source map to the correct field in the destination? Check especially for status fields, custom categories, and numeric values that may be rounded or reformatted. I have seen 'job complete' in ServiceTitan map to 'invoice pending' in QuickBooks because the status values were never aligned.
• Error handling: What happens when a record fails to sync? Is there an exception queue? Are failures logged and reviewed? Or do they fail silently and disappear? Silent failures are the most dangerous because they are invisible until they cause a downstream problem.
• Timing and reliability: Does the sync run on schedule? Are there delays that affect downstream workflows? Does timing vary during peak usage or month-end? A sync that runs every hour except during close is a sync that will break your close process.
• Update handling: When a record is updated in the source, does the destination receive the update? Or does the sync only handle creation, leaving updates to manual correction? Many integrations are one-way on creation and forget that customer addresses, job statuses, and invoice details change.

How to run a health check in under 2 hours

List every integration your company runs. For each, identify the source system, destination system, and the business process it supports. Pick the three highest-risk integrations—the ones that affect billing, reporting, or customer delivery.

For each selected integration, run the five checks on a sample of recent records. Document failures. Categorize them by severity: critical (affects revenue or compliance), high (creates manual work), medium (cosmetic or occasional). The output is a one-page health report with a priority list.

The two-hour timebox is important. It forces focus on the highest-risk integrations and prevents analysis paralysis. You do not need to check every integration in exhaustive detail. You need to find the broken ones that are costing you money.

Common failure patterns by integration type

CRM to dispatch: Missing custom fields, duplicate customer creation, and status mismatches that send unqualified leads to scheduling. I have seen CRMs pass 'prospect' status to dispatch as 'ready to schedule,' resulting in technicians arriving at homes where the customer never confirmed.

Dispatch to billing: Job completion status does not trigger invoice creation. Technician time entries do not map to billing line items. Material usage is lost. The billing clerk has to reconstruct the invoice from memory, photos, and notes. This is one of the most expensive gaps because it directly affects revenue timing and cash flow.

Billing to QuickBooks: Invoice totals mismatch. Class or branch codes are dropped. Payment terms are defaulting incorrectly. Tax calculations differ. These are the most expensive integration failures because they affect financial reporting and tax compliance. An incorrect tax calculation that persists for months can create liability that far exceeds the cost of fixing the integration.

QuickBooks to reporting: Chart of accounts inconsistencies between locations. Timing differences between invoice date and posting date. Manual journal entries that do not flow to the BI tool. The result is a dashboard that leadership does not trust and a reporting team that spends more time reconciling than analyzing.

Building a repeatable health check habit

One health check is useful. A quarterly health check habit is transformative. Schedule two hours every ninety days. Rotate ownership between operations and technical staff so both perspectives stay sharp. Use the same checklist each time so trends are visible.

Track metrics over time: number of critical failures, number of high-severity failures, average time to detect a sync issue, and percentage of records that pass all five checks. Improving metrics prove progress. Flat or worsening metrics indicate that fixes are not durable or that new integrations are introducing new problems. Review trends quarterly and adjust priorities.

Share results with leadership. A one-page health report every quarter keeps backend reliability on the agenda and justifies budget for deeper fixes when needed. It also prevents the 'everything is fine until it is not' surprise that derails month-end and damages credibility.

When a health check reveals a problem you cannot fix internally

Some integration failures require architectural fixes: rebuilding sync logic, redesigning data models, or replacing a tool that cannot support the required data shape. If your health check reveals critical failures and your internal team has already tried to fix them twice, it is time to escalate.

Bring in a backend systems specialist who can evaluate integration architecture, not just configuration. The specialist should produce a findings document with root causes, not just recommendations to 'check the settings.' You need someone who can trace the data flow end-to-end and identify where the logic breaks.

A good escalation test: can your internal team explain why the integration fails? If the answer is 'we are not sure' or 'it just breaks sometimes,' the problem is probably architectural. Configuration issues have clear causes. Architectural issues have intermittent, confusing symptoms that resist simple fixes. Escalate when the explanation is missing or when the same fix has been attempted more than twice.