Salesforce integration engineering
This page is about the seam between Salesforce and your own software. Almost every problem we are called into traces back to one unmade decision: which system owns which fact. Everything downstream gets easier once that is written down.
01Capabilities
What we build on our side of the boundary
The interesting engineering on a Salesforce project usually sits outside Salesforce. It is the software the CRM has to stay in step with, and the connection between the two, which is platforms development and integration work.
- Flows
Accounts, entitlements and usage moving both ways
Accounts, contacts, opportunities, entitlements and usage crossing in both directions. The hard part is never the API call. It is deciding which system wins per field, and what to do when both sides changed the same record since the last sync.
- Events
Change data capture instead of a nightly batch
Platform events and change data capture rather than polling and file drops, with handlers that can run twice safely, replay after an outage and a dead-letter path. Batch looks cheaper right up to the first day the numbers disagree and nobody can say why.
- Migration
Loading data in without inheriting the duplicates
Deduplication, external ID mapping and a reconciliation report somebody actually reads, so divergence is caught by a job rather than by a customer. Where the volumes justify it, this becomes data engineering work rather than integration work.
- Services
Rules that need a repository, tests and a review
Pricing, eligibility and regulated calculations built as your own service and then exposed to Salesforce, see custom software development. Logic living inside the CRM is code without any of those three things.
02Fit
Inside the platform, or inside your own system?
Most Salesforce integration trouble traces back to that one unmade decision. Write it down and the engineering becomes ordinary. Skip it and you get two systems confidently disagreeing, plus a monthly ritual of correcting records by hand. Four of the six rows below send you somewhere other than a Salesforce project with us, and two of those name no unicrew page at all.
| Your situation | What we recommend |
|---|---|
| A standard sales or service process that configuration can express | Take it elsewhereA Salesforce implementation partner will do it faster and cheaper than any engineering team, and configuration is the right instrument for a process that fits. |
| Pricing, entitlement or a regulated calculation your product also relies on | Keep it outsideSalesforce reads that answer; it does not own it. In fintech, and anywhere with an audit obligation, this is not a preference. |
| Reporting that pulls large volumes of history back out of the CRM | Not in the CRMShip the data to a warehouse and report there, see data engineering. CRM reporting stops being the right tool well before the data stops fitting. |
| The integration today is a nightly export plus manual corrections | Replace the mechanismDo that before adding a single feature. Event-driven sync with a reconciliation report costs less than the corrections do, and it makes the disagreements visible. |
| You are still choosing between Salesforce and a lighter CRM | Different pageOur HubSpot page. Decide on process complexity and on who will administer it, never on a feature list. |
| Salesforce is chosen and nobody owns the data model | Stop firstField ownership and the object model come before any integration. Otherwise the integration becomes the place where every unresolved argument surfaces. |
Scope
What we own here is the seam. The contract between the two systems. How it behaves when one of them is down. How a failed window is replayed afterwards. A defensible answer to which record is right when the two disagree. unicrew has been building custom software since 2012, with 100+ senior in-house engineers across six countries. We work under an ISO 27001:2022 certified information-security management system. Your Salesforce configuration stays yours, and we would rather set that boundary plainly than blur it.
03Delivery
How the ownership decision turns into working software
Four steps, and the first is a document rather than code for a good reason. It is the artefact that settles the arguments the next two years would otherwise produce.
- Write down which system owns which fieldPer object and per field, including the awkward ones both sides believe they own. It is a one-page artefact, and it prevents most of what an integration would otherwise generate in its second year.
- Design against the platform limits from day oneAPI limits, bulk against streaming, batching and backoff, sized against your real peak rather than an average. Limits discovered during a launch are the classic way a working integration becomes an incident.
- Make every sync replayable and safe to run twiceEvents carry keys, handlers tolerate a repeat, and a failed window can be replayed without duplicating records. Outages are certain, so the design assumption is recovery rather than uptime.
- Ship the reconciliation report with the integrationA scheduled comparison that reports divergence between the two systems, not an alert that only fires when an API call errors. Verified through our QA and test automation practice rather than by a spot check after go-live.
04Stack
What sits on our side of the seam
The lighter CRM the decision is usually weighed against, and the parts we build and run ourselves. Each has its own page.
05Questions
The questions we answer before writing any integration
Asked on most first calls, answered the way we would answer them live.
Be precise, because the honest answer splits. Engineers to build and own the integration and the services around Salesforce, yes: design reviewed by an architect outside the delivery team, and the same QA practice as our own projects. Administrators to configure your org and run an implementation is a different discipline. Capacity is managed teams; an outcome is platforms development and integration.
No, and we would rather be blunt than imply otherwise. Org configuration and implementation are a different discipline with different people. What we do is the engineering on the other side of the boundary: the product, the services, the integration and the data path, plus the judgement about what should never have gone into the CRM at all.
A question about process complexity and administration, not features. Salesforce assumes somebody owns the org: it models territories, approval chains, complex quoting and a bespoke object graph, and it degrades expensively without that owner. HubSpot assumes the opposite and stays coherent for a smaller team, then fights you when the process gets genuinely complicated. If you cannot name who will administer it, that is your answer.
In your own service whenever the same rule matters outside the CRM, which is more often than it first appears. Pricing, entitlement, eligibility and anything auditable belong somewhere with a repository, tests, review and a deploy history. Apex is right for behaviour genuinely about the CRM record lifecycle and nothing else. If a second consumer would need the same answer, it is a service.
A scoping call with an engineer. For integration work we want two things beforehand: the object and field model as it stands, and an honest description of how data moves today, including the spreadsheet steps nobody enjoys admitting to. What comes back is written: the ownership split, the integration design, and what we would keep out of Salesforce. Most engagements start within two to four weeks.
Three shapes, and which fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based, offered once the first read is done, because a fixed number on an integration nobody has opened is a guess with a contract around it. Team extension is billed monthly per engineer.
Salesforce and your own software drifting apart?
Tell us what has to cross the boundary and in which direction. You get an engineer's read on the design, including the parts we would keep out of the CRM.