Salesforce integration options: connectors, iPaaS, MuleSoft or APIs

There are six realistic ways to connect Salesforce to another system: a vendor-built connector, an iPaaS or middleware platform, MuleSoft, custom code on Salesforce APIs, data virtualization, or scheduled file loads. The right one depends on which way data moves, how much of it, how fast, and who will maintain the link. Most companies end up using two or three of these side by side, chosen flow by flow.

Which questions decide the integration approach?

Seven questions narrow the field quickly. Answer them for each data flow, not for the system as a whole, because one ERP link can contain flows with very different needs.

• Direction: does data move one way, both ways, or does one system only need to read the other?
• Volume: are you moving dozens of records a day or hundreds of thousands in a nightly run?
• Latency: must a change appear within seconds, or is a morning refresh good enough?
• Transformation: do fields map one to one, or do records need merging, splitting and lookups?
• Error handling: what happens to a record that fails, and who is told?
• Ownership: will your admin, a developer, an integration team or a vendor keep it running?
• Number of systems: is this a single pair, or the third and fourth system feeding the same customer data?

The last two questions matter more than most buyers expect. A clever build that nobody on staff can support becomes a liability after the first release cycle.

When is a vendor-built connector or AgentExchange (formerly AppExchange) package enough?

A packaged connector is enough when the flow is standard and you accept the vendor's data model. Syncing invoices from a billing tool or contacts from a marketing platform often fits.

These products install quickly and need little code. The vendor handles authentication, field mapping screens and most API changes on their side. The trade-offs show up later.

• You inherit the vendor's mapping logic, and custom objects or unusual fields may be unsupported.
• Your upgrade timing depends on the vendor, including fixes after a Salesforce release.
• Error reporting is often a log screen that someone has to remember to check.
• Leaving the product later means rebuilding the flow, because the logic lives inside it.

One Abstrakt client, a commercial real-estate firm, used a Google Analytics connector with Marketing Cloud Account Engagement to capture UTM data and first-touch attribution automatically. That is a good example of a standard flow where a connector beats a custom build.

What does an iPaaS or middleware platform add?

Middleware adds a central place to build, schedule, monitor and retry integrations across many systems. It suits companies with several flows and someone able to own the platform.

Most integration platforms offer prebuilt connectors, visual mapping, queues and alerting. They separate integration logic from both endpoints, so swapping one system out touches fewer pieces. The cost is another subscription, another set of skills, and another system that needs an owner.

A manufacturer we worked with used Boomi to link its NetSuite ERP to Salesforce, so reps had one trusted record of each customer. Middleware made sense there because the ERP link carried core customer and order data.

Where does MuleSoft fit, and what is MuleSoft for Flow?

MuleSoft is the integration platform Salesforce owns. Anypoint Platform targets organizations building a reusable API layer across many systems, while MuleSoft for Flow: Integration brings connectors into Salesforce Flow.

Anypoint is the heavier option. It covers API design, runtime hosting, monitoring and governance, and it pays off when several teams consume the same system APIs. Our MuleSoft implementation guide covers when it is worth the investment and how a rollout runs.

MuleSoft for Flow: Integration, previously sold as MuleSoft Composer, lets admins use external-system triggers and actions inside flows. Salesforce documents examples such as creating a NetSuite sales order when an order is created in Salesforce. It fits simple, low-volume flows that an admin team can own.

For a biotech client, Abstrakt built MuleSoft integrations between Salesforce, NetSuite and Stripe that sync payments automatically and handle errors. Before that, an administrator moved the payment data by hand.

When should you build on Salesforce APIs directly?

Build custom when the flow is specific to your business, no packaged option fits, and you have developers who will own the code. It gives full control at the price of full responsibility.

Salesforce exposes several interfaces, and each suits a different shape of traffic.

• REST API: record-level reads and writes for apps that call Salesforce on demand.
• Bulk API 2.0: asynchronous loads and extracts of large record sets.
• Platform Events: custom messages your code publishes when a business event occurs.
• Change Data Capture: events Salesforce publishes automatically when records are created, updated or deleted.
• Pub/Sub API: a gRPC interface external systems use to publish and subscribe to those events.

Outbound calls from Salesforce use Apex callouts. Store endpoints and secrets in Named Credentials and External Credentials, never in code or custom settings. Every one of these routes draws on org limits, so read our guide to Salesforce API limits before sizing the design.

A payments ISO we supported used a custom API integration to its payment processor for automated underwriting submission and merchant ID capture. No packaged connector covered that processor-specific workflow.

Can you show external data without copying it into Salesforce?

Yes, for read-heavy cases. Salesforce Connect and Data Cloud zero copy let users or processes see external data where it lives, instead of syncing it on a schedule.

Salesforce Connect presents external tables as external objects through adapters such as OData or the cross-org adapter. Users can see order history from an ERP on an account page without storing it. It is a paid add-on, and every page view queries the external system live.

Data Cloud, now also branded Data 360, offers zero copy federation with warehouses and lakes. Salesforce names Snowflake, Databricks, BigQuery and Redshift among them. That suits analytics, segmentation and AI grounding more than transactional updates. Confirm current connector support and licensing with your account team.

Are scheduled file transfers still a valid choice?

Yes. A nightly CSV or flat-file load is still sensible for slow-changing reference data, legacy systems without APIs, and partners who can only send files.

File loads are easy to reason about and easy to replay. They break down when users expect current data, when files arrive late or malformed, or when nobody watches the job. Treat them as a real integration, with validation, row-level error output and an owner who reviews failures.

How should integration security be set up?

Give every integration its own user with only the access it needs, and authenticate with OAuth rather than stored passwords. Shared admin logins are a common gap we find.

• Integration user licenses: Salesforce provides API-only Salesforce Integration user licenses, with some included in Enterprise, Unlimited and Performance editions. Check your current count in Setup.
• Least privilege: grant object and field access through permission sets scoped to the flow, not a cloned admin profile.
• OAuth apps: new connections now use External Client Apps, since Salesforce has stopped customers creating new connected apps by default. Existing connected apps keep working.
• Secrets: rotate client secrets and certificates on a schedule, and record who holds them.

Our single sign-on guide covers identity provider setup, OAuth app policies and how integration users fit alongside human logins.

Who should own monitoring and error handling?

A named person or team, agreed before go-live. Every option above fails silently at some point, and the question is how quickly someone notices.

Decide where errors land, who gets alerted, how failed records are retried, and who talks to the other system's owner. Middleware and MuleSoft give you dashboards and retry queues. Custom code needs logging you design yourself. Connectors vary widely, so ask vendors to demonstrate a failed record before you buy.

How do cost and maintenance change over time?

Build cost is the smaller share for most integrations. Licenses, monitoring, Salesforce release testing, and changes on the other system drive the long-term spend.

Connectors trade low build effort for subscription fees and vendor dependence. Custom code shifts the burden to your developers at every release. Middleware and MuleSoft spread platform cost across flows, so they get cheaper per flow as you add more. Our article on integration cost drivers breaks down what moves the price.

How do the options compare side by side?

What should phase one of a first integration include?

Pick one flow with clear value, build it end to end with monitoring, and prove ownership before adding more. A narrow first release teaches you more than a broad design document.

• Choose one flow and write down direction, volume, latency and the system of record for each field.
• Pick the lightest option from the table that meets those needs.
• Create a dedicated integration user and an OAuth app with least-privilege access.
• Define error handling: where failures go, who is alerted, how records are retried.
• Test with real data volumes in a sandbox, including deliberately broken records.
• Document the flow, the owner and the run book before go-live.
• Review after the first Salesforce release to confirm nothing changed underneath it.