Salesforce Is Complicated. The Integration Problems Are Not!

I’ve been spending more time looking at Salesforce recently.

I’m not a Salesforce developer. I’m not about to start writing Apex, and if you put me in front of a complicated Salesforce org and asked me to configure it from scratch, I’d very quickly go and find somebody better qualified.

But I do run a company that spends a lot of time connecting websites, forms, applications and business systems to CRMs.

We’ve worked with Salesforce, HubSpot, Zoho and Microsoft Dynamics in various forms, and increasingly the interesting part of that work isn’t simply connecting two systems. It’s making sure the connection continues to work properly months or years later.

That’s what has made digging further into Salesforce particularly interesting.

Salesforce is complicated, but the problems are familiar

Some of the recent Salesforce developer changes are way outside my personal technical comfort zone.

For example, Salesforce has been experimenting with new Apex integration testing capabilities for Agentforce and Data 360. The developer preview allows certain tests in scratch organisations to interact with the real services rather than mocking everything. (Salesforce Developers: Apex integration tests)

I’m unlikely to personally use that feature but the principle behind it is something I understand very well.

There is a big difference between proving that your code should work and proving that data actually travelled through the real systems successfully.

If you have a WordPress enquiry form connected to Salesforce, HubSpot or another CRM, the useful question is not just “did the form submit?” it’s something more like “did the enquiry make it all the way into the CRM, with the right data, and did everything that was supposed to happen afterwards actually happen?”

That sounds obvious. In practice, it’s where a lot of integrations become much more interesting.

A CRM integration is not really a one-off job

This is probably the biggest thing I’ve taken from looking more closely at Salesforce and the other major CRM platforms.

The old mental model is something like:

Website > API > CRM > done!

But none of those pieces stand still and you have Salesforce changes APIs and authentication methods. HubSpot changes validation rules and how parts of its API behave. Zoho has notification subscriptions that expire and need renewing. Microsoft is continuously changing Dynamics, Dataverse and Power Platform.

The connection that worked perfectly when it was launched therefore isn’t guaranteed to work perfectly forever.

Salesforce makes that lifecycle particularly visible

Salesforce lets developers target versions of its REST API. It also provides a /services/data/latest/ alias which resolves to the newest available version. (Salesforce REST API documentation)

As a non-Salesforce-developer, “latest” initially sounds like exactly what you would want right?

But from an integration point of view, I can see why deliberately choosing and testing an API version can be preferable. You want to understand when an important dependency changes rather than letting production quietly move underneath you.

More critical is that Salesforce is also retiring older authentication approaches. For example, SOAP API login()with the Summer ’27 release, with Salesforce directing integrations towards OAuth and External Client Apps instead. Ouch.

I don’t need to know how to implement every one of those migrations myself to understand the business risk.

If we inherit a website that sends commercially important data into Salesforce, we need to know how that connection works, who owns it and whether any of the technology underneath it has an expiry date.

And this definitely isn’t just a Salesforce problem

The more CRM platforms you look at, the more the same pattern appears and HubSpot recently changed part of its Conversations API so a previously valid way of adding comments to Help Desk threads now returns a validation error. (HubSpot developer changelog).

Zoho’s Notification API uses channels that expire and therefore have to be renewed if you want to continue receiving events. (Zoho CRM developer documentation)

Microsoft has moved Dynamics 365, Power Platform and Dataverse away from its old periodic release-plan model towards a continuously updated roadmap. (Microsoft Dynamics 365 release plans)

None of this is particularly glamorous but it is mostly good old-fashioned maintenance, monitoring and understanding your dependencies.

The bit I actually care about is if the lead arrived?

This is where CRM integration starts to overlap with how we already think about website reliability at Make Do. A website being online does not necessarily mean it is working properly! And likewise, a form showing a nice green “thank you” message does not prove that the enquiry successfully reached Salesforce.

There might be several steps after someone presses submit:

• The website validates and stores the enquiry
• An integration sends it to the CRM
• The CRM validates the record
• Fields are mapped into the right places
• An automation assigns it to somebody
• Another workflow might trigger emails, tasks or downstream systems

Any one of those things can fail so the integration work I find most interesting is therefore less about saying “yes, we can connect WordPress to Salesforce” and more about being able to answer if it is actually still working?

What I now want to know when we inherit a CRM-connected website

This is becoming an increasingly important part of how I think about adoption and rescue work.

• Which forms and applications send data into the CRM?
• How does the integration authenticate?
• Which API does it use and which version?
• Who owns the credentials and integration configuration?
• What happens when the CRM rejects a record?
• Is the original enquiry retained so it can be recovered?
• Are failed transactions retried?
• Are important CRM field, pipeline or stage mappings documented?
• Does anybody get alerted when something breaks?
• When did somebody last deliberately test the complete journey?

That last one is probably my favourite because a test does not need to be clever, it just needs to work.

This is the kind of RevOps work that makes sense to me

The term “Revenue Operations” can easily turn into a vague label covering dashboards, sales processes, marketing automation, AI and a hundred other things.

The part that fits naturally with what we already do at Make Do is much more concrete because it happens when a customer has put commercially important information through a lead capture form:

Did it reach the system it was supposed to reach?

Can you prove that it did?

And if it did not, can you find it and recover it?

The more I learn about the beast that is Salesforce and the other CRM platforms, the more convinced I am that this is where the interesting work is because without a working sales process you have no pipeline!