How to audit a CRM integration and commercial follow-up workflow

## Audit the commercial flow, not only the connector A CRM integration can return successful API responses while the commercial process still fails. A complete audit follows a lead from its first entry point to its final business outcome and asks who owns every handoff. Start with one representative journey: form submission, enrichment, assignment, outreach, reply, qualification, and closure. Record which system writes each field and which event moves the record forward. ## Map systems of record and contracts For every critical object, define: - the system of record; - the unique identifier and deduplication rule; - required and optional fields; - allowed values and transformations; - which system can overwrite each field; - expected timing: synchronous, event-driven, or batch. Salesforce’s integration patterns distinguish process, data, and virtual integration and recommend selecting a pattern according to timing, volume, transactionality, and failure handling. The audit should make that choice explicit rather than accepting an accidental point-to-point chain. ## Inspect failure behavior List what happens when a dependency is slow, unavailable, or returns incomplete data. Check retries, timeouts, idempotency, dead-letter handling, and operator notifications. A retry must not create a second lead, duplicate an activity, or advance a workflow twice. Test with deliberately broken inputs: missing email, malformed phone number, duplicate external ID, expired credentials, rate limits, and a downstream timeout. The useful result is not only whether the system recovers, but whether an operator can see what happened and act on it. ## Verify ownership and follow-up rules For each transition, write down: 1. the event that starts the step; 2. the person or team responsible; 3. the expected response time; 4. the evidence that the step occurred; 5. the exception path. A task without a named owner is not a handoff. A status without an event trail is not reliable evidence. If sales and operations use different definitions, fix the shared state model before adding automation. ## Design observability around business outcomes Microsoft’s monitoring guidance recommends treating observability as an architectural capability. For a CRM flow, technical telemetry should connect to operational signals such as records received, assignment success, time in each state, failed writes, retry volume, and unresolved exceptions. Use correlation IDs across the form, integration, CRM, and outreach tool. Keep operational logs separate from the designated system of record: logs help explain behavior, but the agreed CRM or database should retain the authoritative business state. ## Test before activation Use test records that cover the normal path and each meaningful branch. HubSpot’s workflow guidance separates testing enrollment criteria from simulating the actions a record will follow. Apply the same discipline to any CRM: verify both whether a record enters the workflow and what happens after it does. Document expected results and compare them with observed state in every connected system. Repeat the test after changes to fields, credentials, or workflow conditions. When the audit shows that handoffs and systems of record are the real bottleneck—not another connector—see how we approach data and systems integration. ## The audit output A useful audit ends with a prioritized list, not a diagram alone: - critical correctness or security defects; - silent failure and observability gaps; - ownership and process ambiguities; - duplicate or unnecessary automation; - changes that can be tested independently; - rollback and operating instructions. This evidence helps separate process decisions from implementation work. That prevents a new integration from simply moving the same ambiguity to another tool.