When companies set out to hire Salesforce integration services, or a partner to deliver them, Salesforce expertise in the narrow sense is usually the one thing they already have. There’s an org, and often a partner who configured it. What they need is someone to connect that org to the systems that run the rest of the business – the ERP that owns invoices and inventory, the billing platform that owns subscriptions, the data warehouse that finance and analytics depend on, and the older systems nobody wants to touch. That work sits right next to Salesforce, but technically it’s a different animal, and choosing a firm to do it well is a different exercise from choosing one to implement Sales Cloud.
I’ve written this guide for buyers at the point of decision, and for Salesforce partners who need to bring in integration capacity for a client. It covers the kinds of firm you’ll come across, the questions that tell them apart, what a good proposal contains, the red flags worth taking seriously, how to structure a first engagement, and what the first thirty days should look like. At the end, there’s a scorecard you can use to compare shortlisted firms side by side.
Why integration is a separate hiring decision
Most Salesforce integration projects that go wrong do so on the other side of the line, in the system the Salesforce team understands least. The questions that decide the outcome are rarely about Apex or Flow. They’re about which system owns the customer once it has a financial history, what happens when an order is amended after it has already reached the ERP, how the design respects the ERP’s API limits and governance rules, and how anyone is going to prove, every month, that the two systems agree. A firm can be excellent at configuring Salesforce and still have very little experience with any of that.
Integration also fails in its own way. A bad page layout annoys users on the first day, and they tell you about it. A badly designed synchronization can corrupt data quietly for weeks, and by the time finance notices that the revenue numbers in the two systems differ, the damage has spread into reports, commissions and invoices.
Four kinds of firm, and when each fits
Broadly, the market offers four options, and each of them is the right one in some situations.
Salesforce implementation partners know the platform deeply, and they often know your org already. Many have some integration capability, which can be anything from a strong practice to one or two people who have connected an ERP before. They’re a natural choice when the integration is modest and the platform work is most of the job. The risk is that integration ends up as the part of the project the partner is least equipped for and least interested in – and so it tends to get scheduled late.
Integration specialists are firms whose business is the layer between systems. They work across platforms instead of inside one, and their experience is with the ways things fail: duplicates, ordering, retries, reconciliation, cutover. They’re the right choice when the integration is the riskiest part of the program, when more than one non-Salesforce system is involved, or when an existing integration needs repair. The best of them don’t run a Salesforce implementation practice, which matters a great deal if you’re a partner bringing them into your own client.
Freelancers and independent contractors can be excellent, particularly for a well-defined connector or a single data flow. Their limitation is continuity. An integration that runs your order-to-cash process needs someone to pick up the phone at month-end, and someone to take over when that person moves on, and one individual can’t always offer either.
iPaaS vendor services – the professional services arms of integration platform vendors – know their own product thoroughly and can stand up a platform quickly. Naturally, their incentive is to solve the problem with that platform, and they may have less to say about whether the design suits your systems of record, or about the parts of the problem the product doesn’t cover.
| Firm type | Strongest when | Watch for |
|---|---|---|
| Salesforce implementation partner | The integration is small and platform work dominates | Integration treated as an afterthought; thin ERP experience |
| Integration specialist | Several systems are involved, the data risk is high, or an integration needs rescuing | Firms that also sell platform work and may compete with your partner |
| Freelancer | One well-scoped connector, with a clear owner afterward | Continuity, support coverage, and key-person risk |
| iPaaS vendor services | You’ve chosen the platform and need it stood up | A design shaped by the product more than by the problem |
Questions to ask before you shortlist
The useful questions are concrete ones, and the answers are easy to judge once you know what a good answer sounds like.
Ask which non-Salesforce systems the firm has integrated with Salesforce, and ask them to walk you through one in detail – the objects, the direction of each flow, the mechanism and the volume. A firm that answers in the ERP’s own concepts (posting periods, item fulfillments or IDocs, say) has worked on that side of the line. A firm that answers only in Salesforce terms probably hasn’t.
Ask how they decide the system of record for each object, and, for two-way synchronization, for each field. Ask how their integrations deal with a duplicate event, an event that arrives out of order, and a downstream system that’s unavailable for an hour. Good answers talk about idempotent processing, retry with backoff, dead-letter handling and replay. Weak answers tell you the platform “handles it”.
Ask how they approach Salesforce’s API limits and which APIs they’d use at which volumes, including the Bulk API for large loads and event-based mechanisms such as Platform Events or Change Data Capture where those fit. Ask how they test a data migration, and whether they rehearse it at full production volume. Ask what reconciliation they build, and who gets to see it. And ask who will actually do the work, whether you can talk to those people before you sign, and what happens if one of them leaves.
If you’re a Salesforce partner hiring for a client, add the questions that protect your account. Will they work under your brand and inside your tools? Will they sign your agreements? Do they run a Salesforce practice of their own, and will they sign a mutual non-solicit? Our guide to white-label subcontracting goes into these in more depth.
What a good proposal contains
A proposal tells you more about a firm than its sales conversation does, because it shows how the firm thinks when it has to put something on paper and stand behind it. A good one restates the problem in the firm’s own words, and gets it right. It contains an interface inventory that lists each integration and data flow with its source, target, direction, mechanism, frequency and expected volume. And it states which system owns each object, or proposes to decide that early.
It sets out acceptance criteria that can actually be tested, including reconciliation between the systems involved – a line like “integration works as expected” doesn’t count. It lists its assumptions explicitly, so you can see what would change the estimate. It treats error handling, monitoring and alerting as part of the build itself, and never as optional extras. And it names the people, the governance cadence and the handover: documentation, runbooks, and a walkthrough for whoever will maintain the integration.
If you’d like to see this structure in practice, our integration SOW template lays out the interface inventory, systems of record, acceptance criteria and assumptions in a form you can fill in, and the article on scoping integration work in a statement of work explains the reasoning behind each section. Holding proposals up against that structure is a quick way to see which ones have been properly thought through.
Red flags
Some warning signs are worth acting on even when everything else about a firm looks good.
A proposal with a fixed price and no interface inventory has priced something, though it’s hard to say what. A firm that can’t explain how it handles duplicates or failures will find out the answer in production, at your expense. Senior people who are present throughout the sales process and vanish once the contract is signed are a common pattern, and the remedy is to name the delivery team in the contract. And a proposal that treats data migration as a line item, when it should be a workstream with its own rehearsals and reconciliation, is underestimating the riskiest part of most programs.
Be cautious, too, of firms that insist on their own middleware or accelerator as a precondition, unless you’ve chosen that platform for good reasons of your own. And if you’re a partner, be wary of an integration firm that also sells Salesforce implementation. It may be entirely honest, but its position makes it a competitor for your client all the same.
Structuring the first engagement
The first engagement with a new firm should be small enough to be cheap if it goes wrong, and real enough to show you how the firm works. Two shapes work well. One is a single, bounded integration with clear acceptance criteria – account and contact synchronization with the ERP, for example – delivered to production with monitoring and reconciliation. The other is a short assessment or design phase that produces an interface inventory, systems-of-record decisions and an estimate for the full build, all of which you own whether or not you continue with the same firm.
Either way, you get evidence about the things that matter most: the quality of the engineering, the honesty of the status reporting, and how the firm behaves when it runs into something it didn’t expect. A firm that will only take on a large program from day one is asking you to accept that evidence on trust.
A client example. A components manufacturer wanted its Salesforce accounts synchronized with its ERP, but it didn’t want to commit to a six-month integration program on the strength of a slide deck. So our first engagement was fixed-price and deliberately narrow: customer master changes approved in the ERP flowed one way into Salesforce, with an exception report alongside. The ERP owned billing identity, tax data and payment terms, and Salesforce kept sales contacts and opportunity relationships. The work turned up several thousand near-duplicate Salesforce accounts, and we chose not to merge them automatically. We built a customer crosswalk, normalized addresses, separated legal entities from ship-to sites, and required finance approval for any merge that touched an ERP account number. We also took the integration down on purpose and showed it replaying cleanly. After six weeks, 98.5% of in-scope records matched automatically and the other 1.5% went to business review. The order-status and inventory phase that followed was a separate decision, with its own statement of work.
What to expect in the first thirty days
The first month of a well-run integration engagement has a recognizable shape. In the first week, access gets provisioned, the integration firm meets the platform owners on both sides, and the interface inventory is confirmed or corrected. By the end of the second week, the systems-of-record decisions are written down and signed off, and the integration design (error handling and monitoring included) has been reviewed. By the end of the third week, the first flow is running end to end in a non-production environment with representative data. And by the end of the fourth, there’s a reconciliation report comparing the two systems, a first draft of the runbook, and a status report that names the risks plainly.
If all the first month has produced is meetings and diagrams, the engagement is drifting. Working software and a reconciliation report are the only kind of status that can’t be optimistic.
A scorecard for comparing firms
Score each shortlisted firm from one to five on each criterion, multiply by the weight, and compare the totals. The weights below suit a typical ERP or billing integration, so adjust them to fit your own situation.
| Criterion | Weight | What a 5 looks like |
|---|---|---|
| Depth on the non-Salesforce systems involved | 20% | Explains your ERP or billing platform in its own terms, with detailed past examples |
| Data integrity approach | 15% | Describes systems of record, idempotency, retries, dead letters and replay without being prompted |
| Reconciliation and monitoring | 10% | Reconciliation is built into acceptance; alerting and runbooks are in scope |
| Quality of the proposal | 15% | An interface inventory, testable acceptance criteria, explicit assumptions |
| Migration approach | 10% | Full-volume rehearsals with reconciled results, and a rollback path |
| Named delivery team | 10% | You’ve met the engineers who will do the work, and the contract names them |
| Handover and independence | 10% | Documentation, runbooks and a walkthrough; no proprietary dependency left behind |
| Willingness to start small | 5% | Offers a bounded first engagement whose output you own |
| Fit with your commercial position | 5% | For partners: works under your brand, signs your paper, doesn’t compete for your client |
Related reading
- NetSuite Salesforce integration: keeping CRM and ERP in agreement
- Integration reconciliation reports: proving two systems agree
- How to scope integration work in a statement of work
How we approach it at eProxim
eProxim is an integration engineering firm, founded in 1997. On Salesforce work, we take everything outside the org boundary: ERP and finance integration, external APIs, event streaming, data migration and synchronization. We don’t run a Salesforce implementation practice, we don’t bid against partners, and we sign a mutual non-solicit on Salesforce work, so a partner can bring us into a client account without inviting in a competitor. Idempotent processing, retry and dead-letter handling, audit trails, observability and a rollback plan come as standard in everything we build – they aren’t options you have to ask for.
Our services for Salesforce partners page explains how we work alongside a platform team, including under a partner’s brand. If you’re deciding who should build your Salesforce integrations, start a conversation with us.