Not verified hands-on. This article was written from primary documentation rather than reproduced in an org, so it carries no tested-release badge. If you run it and something differs, say so in the comments and it gets tested and corrected.

The short version: build it natively in Salesforce when the integration is point to point, low volume, and owned by the Salesforce team. Buy middleware when you have several systems that all need to talk to each other, when the transformation logic is real work, or when you need retries, queuing and monitoring you would otherwise hand-build. MuleSoft is not the only middleware and it is rarely the cheapest. The question is whether you need middleware at all, and only then which.

What native actually covers now

The platform’s own integration surface is better than its reputation, and a lot of MuleSoft deployments exist because someone last looked at this in 2016:

  • Named Credentials and External Credentials handle authentication, token refresh and certificates declaratively, so your Apex contains no secrets and no OAuth dance.
  • External Services imports an OpenAPI definition and generates invocable actions you can call from Flow without writing Apex at all.
  • HTTP Callout in Flow covers simple synchronous calls for admins.
  • Platform Events and the Pub/Sub API give you asynchronous, replayable outbound messaging.
  • Salesforce Connect exposes external data as external objects without copying it, which is the right answer surprisingly often.
  • Bulk API 2.0 handles volume in both directions.

Native falls down in specific places. Apex gives you 100 callouts per transaction and a total callout time budget per transaction measured in a couple of minutes. There is no built-in durable retry queue, so you build one with platform events or a custom object and a scheduled job. Orchestrating a four-system process in Apex means writing a state machine, and you will write it badly the first time.

What middleware is genuinely buying you

Three things, and it is worth being precise because vendors sell all ten:

A place for logic that belongs to neither system. When an order in Salesforce becomes three records in an ERP and a message to a warehouse, that mapping is not Salesforce’s business and not the ERP’s. Put it in Apex and the Salesforce org becomes the integration hub by accident, which is how orgs end up with 40,000 lines of translation code nobody dares touch.

Operational machinery. Retry with backoff, dead letter queues, replay of a failed message, throughput throttling, per-interface dashboards. You can build each of these on the platform. You will not build all of them well.

Reuse across consumers. An API that three systems call, of which Salesforce is one. If Salesforce is the only consumer, this benefit is zero, and it is the benefit most often cited.

The cost question

MuleSoft is licensed by capacity rather than by integration, so the cost does not scale down for a small footprint. A two-interface deployment pays close to what a twenty-interface deployment pays, which is why the platform only makes financial sense once you have a real portfolio. Against that, native development costs developer time and produces something only your team can maintain.

The comparison people forget is the third option: a smaller integration platform. Plenty of tools do queuing, retry and mapping for a fraction of the price and will happily handle six interfaces. Choosing between “build it in Apex” and “buy the enterprise platform” is a false pair, and it is how organisations with four integrations end up with a licence they cannot justify at renewal.

A usable decision rule

  • One system, simple mapping, moderate volume. Native. Named Credentials, a queueable, a retry table.
  • One system, but the data is only ever read. Salesforce Connect, and copy nothing.
  • Salesforce as the event source for several consumers. Platform events plus Pub/Sub, with each consumer managing its own subscription.
  • Three or more systems, shared canonical model, a team that owns integration as a discipline. Middleware.

One more consideration that decides more cases than architecture does: who gets paged at 3am. If the answer is the Salesforce team either way, native keeps the debugging in one place. If there is an integration team with a platform they already run, adding a Salesforce interface to it is cheaper than teaching them Apex.

Frequently asked

Does owning Salesforce mean we should use MuleSoft? No. Shared ownership makes the commercial conversation easier and changes nothing about whether the tool fits.

Can we start native and move later? Yes, if you keep the integration logic out of triggers and behind a clean interface. Business logic tangled into a trigger is what makes the migration expensive, not the callout code.

What about the API limit? Middleware does not reduce inbound API consumption. It can increase it by polling. Batching and event-driven patterns reduce it. That is a design choice, not a product choice.