The expensive problem is rarely Salesforce itself. It is that Salesforce does not know what the billing system knows, the support desk does not know what sales promised, and somebody spends a day a week keeping the two in agreement by hand. Integration work is what removes that person from the middle.
What I connect
- Third-party SaaS — billing and invoicing, support desks, marketing platforms, e-signature, accounting, HR systems.
- Internal and legacy systems — your own back end, an ERP, a database or an API that was written before anyone thought about integration.
- Salesforce to Salesforce — org-to-org sync after an acquisition, or between a production org and a partner's.
- Data migration — bringing records in from a spreadsheet, another CRM, or a system being retired, with the mapping and deduplication that makes the result usable.
The parts that decide whether it holds up
Direction and ownership
Before any code, one question has to be answered per field: which system is the source of truth? Two-way sync without a clear owner creates records that flip back and forth and a support ticket nobody can explain. Most integrations I build are one-way for most fields and two-way only where it is genuinely needed.
Errors you can see
Integrations fail. The other system goes down, an API changes, a record arrives with a field your validation rule rejects. The difference between an integration you trust and one you don't is whether those failures are visible and recoverable, or whether they vanish and you find out three weeks later that half the records are missing. I build in logging, retries and a place for a human to look.
Limits
Salesforce governor limits and API call allocations are not an afterthought. An integration that works for 50 records a day and dies at 5,000 is a common and avoidable mistake. Bulk patterns, batching and platform events exist for this reason.
What I work with
- REST and SOAP APIs, both consuming and exposing them from Salesforce
- Apex callouts, named credentials, queueable and batch processing
- Platform events and change data capture for event-driven patterns
- Bulk API for migrations and high-volume loads
- Middleware where it earns its place — and point-to-point where it does not
On the Salesforce side, integrations frequently need custom screens for the people using the data. That is Apex and Lightning Web Components work, and it is usually the same project.
Middleware or direct?
Vendors will tell you that you need an integration platform. Sometimes you do — several systems, complex transformation, a team that needs to see and change the mapping without a developer. Often you do not, and a direct integration is cheaper to build, cheaper to run and easier to debug. I will tell you which case you are in before you sign up for a subscription you do not need.
How this works
Start with a free 20-minute call: describe the two systems and what should happen when something changes in one of them. I come back with the approach, the direction of data flow per object, what it costs and how long it takes. Everything is built and tested in a sandbox against the real APIs before it goes near production.
Common questions
Can you integrate Salesforce with a system that has no public API?
Sometimes. If there is a database, a file export, an SFTP drop or even an undocumented endpoint, there is usually a path. If there genuinely is not one, I will tell you on the first call rather than after a month of billing.
How long does a typical integration take?
A straightforward one-way integration between two systems with good APIs is usually one to three weeks. Two-way sync, complex transformation or a legacy system on the other end takes longer. You get an estimate before any work starts.
What happens when the integration breaks after you are gone?
That is what the logging and retry handling is for — most failures recover by themselves and the rest surface somewhere a human will see them. I hand over documentation, and I stay available afterwards. Long-term support is part of how I work, not an upsell.