Direct integration vs. an intermediary

Enterprise clients needed document-driven workflows, onboarding, KYC, capital call execution, to run inside the CRM they already lived in, Salesforce, not in a separate tool they had to remember to check. That meant deciding how deeply to integrate with a platform whose internals I didn't control and whose review process wasn't fast.

The same underlying question came up again on a different integration, delivering the same extracted data into a data warehouse, and the two situations pointed to opposite answers.

Two integrations, built to different depths on purpose.

• Event-driven handoff. A completed action on the extraction side fires a webhook that routes to the matching Salesforce flow by document type.
• Typed data contracts. Explicit date, numeric, and boolean export fields, so Salesforce references the right type instead of inferring it from one ambiguous cleaned value.
• UUID-scoped payloads. Document and field identifiers sent rather than full records, so Salesforce gets exactly what it needs.
• Embedded business logic. A value above a threshold routes to a specialized team automatically, rather than every case following the same default path.
• Confirmation checkpoints at each stage, so a failure is visible where it happened instead of propagating silently downstream.

The question about whether to build direct versus intermediary isn't so much a business maturity question as it is about purpose. The real question is what the integration needs to do.

Warehouse delivery was pure data movement. Nothing was lost by using an intermediary, and a lot was gained. No owning schema evolution or retry logic indefinitely, no maintaining a connector for a destination with no strategic reason to be visible in.

The Salesforce integration wasn't data movement, it was workflow. Flows, sequencing, webhook-triggered actions, business rules that had to live somewhere. An intermediary can move data between two systems. It can't express what should happen next inside a platform it doesn't operate in. That required being a first-class citizen of Salesforce's own platform, which meant the package, the review, the cost.

It's a simple question. Does this integration need to be visible and interactive inside the partner's world, or is it simply delivered to a destination?

Delivery, use the tool built for it. Interactive and workflow-bearing, go direct and accept the cost, because the cost buys something a tool can't. Standing inside the ecosystem, not behind it.

There was a second payoff to going direct that had nothing to do with the technical need. Salesforce selected the integration to present at TrailblazerDX as an early production use case for their newly launched Orchestrator product, and it was featured in Salesforce marketing and listed on AppExchange. Being a recognized integration inside a major platform's ecosystem is itself distribution, credibility a pass-through connector never earns because nobody sees it. That's not why the decision was made, workflow depth was, but it's why the decision was worth the review-process pain in the aftermath.

Every growing system accumulates integration decisions, and the trap is applying one default to all of them. Always build direct because you want control, or always use a tool because it's faster. Neither survives contact with a real portfolio of integrations, because they're not the same kind of relationship.

The useful question isn't build or buy. It's what does this specific connection need to do, asked fresh each time, because the answer to a data-delivery problem and a workflow-integration problem is never the same one.