Photo: Scott Rodgerson / Unsplash
Salesforce is most useful when it shares data with the rest of the business: ERP, billing, marketing automation, support and data warehouses. We design integrations that stay reliable after launch, using MuleSoft, Workato or custom APIs depending on what fits.
Salesforce integration connects Salesforce to other business systems so data moves automatically instead of being re-keyed. The work involves deciding which system owns each piece of data, choosing an integration pattern and tool, building and testing the connections, and setting up monitoring and error handling so failed syncs are caught quickly.
System of record for each entity, latency needs, error handling and reconciliation ownership, agreed in writing.
NetSuite and other ERP connections for accounts, orders, invoices and products.
MuleSoft and Workato builds, or custom Apex REST and callouts where a platform is not justified.
Marketing automation, telephony, e-signature and support platform connections.
Alerts and logs for failed syncs, so problems are found by the team rather than by customers.
What happens in each phase, what you get at the end of it, and what we need from your team.
We sit with the people who run each system (finance for the ERP, marketing operations for automation, support leads for the help desk) and trace every record that crosses a boundary. For each entity we note where it is created, who edits it afterward, how many records change on a busy day and what happens today when two systems disagree. Hidden flows surface here: nightly spreadsheet exports, a shared inbox someone forwards, a report copied into the ERP by hand.
Each flow gets a pattern chosen for its job: synchronous API calls where a rep needs an answer mid-conversation, event-driven messages for status changes, scheduled batches for heavy loads. We define external IDs and matching keys, decide how retries avoid creating duplicates, and specify what an error record contains and who receives it. API consumption, field-level security and the integration user's permissions are settled on paper before anyone configures a connector.
Connections are built against sandboxes on both sides wherever the other platform offers one. We push production-like volumes through, then break things on purpose: send a malformed record, take the endpoint offline, edit the same account in both systems at once. Every failure should land in the error queue with enough context to fix it. Historical records are backfilled as a separate load, so the ongoing sync is not flooded on its first day.
After go-live we watch the first business cycles closely, because month-end close, a large import or a price change often exposes edge cases testing missed. Alerts route to named people, not a shared mailbox nobody reads. A reconciliation report compares record counts and key totals across systems so drift is visible early. The runbook explains how to replay a failed message, rotate credentials and pause a flow safely while either platform is under maintenance.
The same work can be a small project or a large one. These are the factors that decide which.
| Factor | Keeps effort down | Raises effort |
|---|---|---|
| Number of connected systems | One or two systems exchanging a small set of objects in a single direction. | Several systems sharing customers, products and orders, each needing its own mapping and test cycle. |
| Direction of data flow | One-way pushes where a single system clearly owns every field that moves. | Two-way sync on shared fields, which requires conflict rules for simultaneous edits. |
| Latency expectations | Scheduled batches, where a nightly or hourly refresh meets the business need. | Real-time lookups or event streams that users depend on during live customer conversations. |
| Condition of the other API | Documented REST APIs with sandbox environments and stable, modern authentication. | Legacy platforms reached through file drops, database views or undocumented endpoints. |
| Record matching keys | Shared external IDs already exist on both sides for accounts and products. | No common keys, so records must be matched on names, addresses or tax IDs. |
| Transformation logic | Fields carry across with light formatting, such as picklist values or date formats. | Pricing, tax, unit-of-measure or currency rules recalculated while data is in transit. |
We price from a written scope after discovery, so these factors are what we ask about first.
Teams often ask for full two-way sync because it sounds safest. In practice it creates update loops, overwritten values and arguments about which number is right. Most fields have one natural owner and should flow one way. Reserve bidirectional sync for the few fields genuinely edited in both places, and write down which side wins a tie.
Connections built on an admin's own credentials break the day that person leaves, resets a password or loses a permission. They also blur the audit trail, because automated changes look like human ones. A dedicated integration user holding only the permissions each flow requires is easier to secure, easier to trace and survives staff turnover.
An integration that performs well with a few hundred test records can stall at production volume. Salesforce enforces daily API allocations and per-transaction limits, and the other platform usually throttles too. Bulk APIs, composite requests, batching and sensible polling intervals keep traffic within bounds. Check consumption during testing instead of finding the ceiling during a busy sales week.
Turning on a live sync without loading existing records leaves reps with partial views: new orders appear, older ones do not, and reports look wrong. Pushing years of history through that same live channel can swamp it. Plan the backfill as its own step with reconciliation, and enable incremental sync only once both sides agree on the totals.
Plenty of partners can connect two systems; fewer design connections your own staff can still operate a year later. When comparing proposals, look past the list of tools and ask how the partner handles data ownership, failure and handover. The answers reveal whether they have supported integrations in production or only built them.
Written by the consultants delivering the work.
When it makes sense to keep HubSpot for marketing and Salesforce for sales, how HubSpot's Salesforce connector decides what syncs, field ownership and sync rules, API usage, lifecycle stages and when to consolidate instead.
Read the full post →Not always. MuleSoft suits companies with many systems and APIs to manage. Workato or a direct custom integration can be the better choice for a handful of connections. We recommend based on data volumes, latency needs and who will maintain it.
Yes. We have integrated NetSuite with Salesforce for a manufacturer, which unified sales and ERP data and helped take Salesforce adoption to all 99 reps, and for a biotech company, which eliminated manual payment entry.
Most failures come from unclear data ownership, no plan for records that do not match, and no monitoring. We cover the common patterns and pitfalls in our guide to Salesforce-to-ERP integration patterns.
MuleSoft, Workato and Salesforce’s native integration tools, chosen by the number of systems, data volumes and who will maintain the integration. We share the certifications of the consultants who would work on your project during scoping.
It depends on the number of systems, the direction of flow and the state of the other platform's API. A single one-way connection between Salesforce and a modern cloud application can often be designed, built and tested in weeks. A program spanning an ERP, two-way sync and a history backfill usually runs for months. The mapping phase is the best predictor, so we firm up estimates once it is complete.
No. Real-time connections take more effort to build and monitor, and they consume more API capacity. They earn their keep when a person or process needs the answer immediately, such as checking credit status while preparing a quote. Invoice history, inventory snapshots and warehouse loads usually work well on a schedule. Many sound designs mix both patterns, choosing per flow rather than per project.
Usually, though the approach changes. Options include secure scheduled file exchange, reading from a database view or replica, or middleware connectors built for older platforms. These routes need tighter reconciliation, because file-based transfers tend to fail quietly. If the legacy system is due for replacement soon, we may suggest a lighter interim bridge instead of a full build that will be thrown away.
Each connection runs under a dedicated integration user limited to the objects and fields it needs. Credentials live in Named Credentials or the middleware's secure store, never in code. Traffic is encrypted and inbound endpoints require authentication. For regulated clients in financial services or healthcare, we also document every data flow so compliance teams can see which information leaves Salesforce and where it lands.
Yes. We start by documenting what exists, since inherited integrations often lack diagrams or error handling. We review the code or middleware flows, check which credentials they run under, and read the logs for recurring failures. That shows whether each connection should be stabilized, refactored or replaced. For a B2B demand-generation firm, replacing tools that would not sync reliably restored bi-directional data across 145,000+ prospects.
A Salesforce Health Check reviews your org and gives you a ranked list of what to fix first, with effort estimates. It is the right starting point before an optimization project, a new cloud or an AI initiative.
Headquartered in St. Louis, working with companies across the U.S.
Discuss your integration →Tech Talk
A monthly brief for the people who own Salesforce, AI and revenue technology
What changed in Salesforce and AI this month, and what to do about it.
One email a month. Written by the consultants who deliver the work, not by a marketing team, for the leaders who make the technology decisions.
Consultant analysis, not vendor recaps. One click to leave.