# MuleSoft on Salesforce: integration, not a data copy

MuleSoft was acquired in 2018 and kept its name. A sandbox does not include it. A spreadsheet load is not the implementation.

**Published:** 2026-02-24
**Canonical:** https://synconai.com/mulesoft-salesforce-implementation
**Author:** SynconAI Architecture Team

## In short

MuleSoft was acquired in 2018 and kept its name. It is an integration platform. It does not copy another system into Salesforce. A Salesforce sandbox does not include MuleSoft. Data 360 is a different product. The bill covers discovery, connection design, error handling, environments, and testing. A daily API cap belongs in the quote only when your contract shows the number.

## Sources

- **About Salesforce Data 360** (retrieved 2025-10-14)
  https://help.salesforce.com/s/articleView?id=data.c360_a_data_cloud.htm&type=5
  > As of October 14, 2025, Data Cloud has been rebranded to Data 360.

## What to take away

- MuleSoft kept its name after the 2018 acquisition. It moves agreed messages. It does not paste another system into Salesforce.
- A Salesforce sandbox does not include MuleSoft. You need a separate runtime, pointed at that sandbox on purpose.
- Data 360 is a different product. The Data Cloud rename does not make an integration flow a Data 360 pipeline.
- The quote lists systems, keys, failures, environments, and a named owner. A daily API cap you cannot show is not a line item.

## The guide

The order feed failed on a Tuesday, and nobody could say which product was supposed to notice. Finance had asked for SAP orders on the Salesforce account so a seller could answer a customer without leaving the page. The plan on the slide said MuleSoft would migrate SAP into Salesforce. What ran on Friday was a spreadsheet import. The import created accounts that already existed. It parked order lines on a custom object no report uses. By Monday the spreadsheet was stale, the duplicates were in the forecast meeting, and MuleSoft had not executed a single message. It was not installed in the sandbox. The product name had been used as a label for a copy, and the copy was already wrong.

The person who owns the integration then asks for a quote. The reply is one number and a line that says data migration. There is no list of systems. There is no external id. There is no statement of what stays in SAP when the load is finished. The buyer cannot tell whether they are buying a connection or a one-off paste. That gap is the failure this page is about. Close it before anyone builds a flow, and do not fill the gap with a daily API cap you cannot point to in a contract.

## An integration platform that kept its name

MuleSoft was acquired in 2018 and kept its name. It is an integration platform. Applications call each other. A message leaves a system of record. A flow decides whether Salesforce may create or update a record. Errors are caught, held, and replayed by a person who owns that queue. The other system can remain the owner of the order. Salesforce can remain the place a seller reads a subset of it.

That is not a data copy into Salesforce. A copy takes a snapshot and pastes rows. An integration keeps a contract. The contract names the event, the object that receives it, the field that is the key, and the behaviour when the source is down. If the plan says "migrate everything", ask which event. If nobody can name the event, you are still looking at a paste, whatever logo sits on the slide.

Keep the names apart in the statement of work. MuleSoft is the platform. Salesforce is the CRM. A sentence that treats them as one product will assign a sandbox task to a runtime the sandbox does not contain. Say which system owns the order. Say which fields a seller may see. Say which fields stay in the source because a seller must not edit them. Those three lines are the design. A folder of mappings without them is a wish.

A search for migration services often means "move our data". For this product the honest scope is narrower. Move the agreed messages. Leave the rest where it is owned. Document the key. Test the failure. If a proposed migration service is a full extract of every table into custom objects, you are buying a copy with an integration label. Send that proposal back. Ask for the event list. A short list you can test is worth more than a long list nobody will run twice.

Write the owner of the source system into the design before the first build day. That person can refuse a field. The integration team cannot invent the refusal later, during a production incident, when a seller has already edited a number that SAP still treats as official. The argument about which number is true is not an integration defect. It is a missing owner. Name them while the quote is still a draft.

## Data 360 is a different product

People searching for a MuleSoft quote land on Data 360 pages because both names sit near the word data. They are not the same product. A MuleSoft flow is not a Data 360 pipeline. A Data 360 ingest is not the order API. If a diagram draws one box and labels it with both names, the diagram is the defect.

Salesforce's help page states the rename, and only the rename, in this sentence: "As of October 14, 2025, Data Cloud has been rebranded to Data 360." Use that sentence to correct a label. Do not use it to claim that MuleSoft changed, merged, or started copying profiles. The sentence does not mention MuleSoft. A rename of a different product does not move your SAP contract into a harmonisation job.

If both products are genuinely in the programme, give each a job in writing. One sentence for the messages MuleSoft may carry. One sentence for the data set Data 360 may hold. If the sentences match, you have one job wearing two product names. The quote will either charge twice or skip the work that actually fails on a Tuesday. Delete one sentence until they describe different outcomes a seller can point at.

Do not describe a MuleSoft flow as profile unification. Do not describe a Data 360 activation as the retry queue for a failed order message. Those are different failure modes, different owners, and different tests. A partner who offers both in one breath should still draw two pictures. You are allowed to buy both. You are not allowed to accept one picture with two logos.

## A sandbox does not include MuleSoft

A Salesforce sandbox copies Salesforce metadata and, depending on the type, some or all of the CRM data. It does not copy a MuleSoft runtime. Refreshing the sandbox does not deploy an API. It does not replay yesterday's messages. It does not connect to SAP because production once did. Anyone who tells you the sandbox already includes MuleSoft should open it and show the flow. The absence is the finding.

You need a MuleSoft environment of its own, pointed at that Salesforce sandbox on purpose. The environment has an owner, credentials that are not a personal login, and a path from a lower environment to the next. Those are line items on the quote. They are not included because a CRM sandbox exists. When the sandbox is refreshed, the Salesforce side moves and the MuleSoft side does not. Plan the re-pointing. A refresh that silently aims a live flow at the wrong org is a production incident caused by a calendar reminder nobody owned.

The same boundary holds in production. Buying Salesforce does not turn MuleSoft on. Keeping the name after 2018 means you still ask for MuleSoft by that name. It does not mean every org has a runtime. Your contract says whether you do. If the contract is silent, the quote must say the runtime is out of scope or must name who will provide it. Silence is how a build starts and then stops for a month while procurement catches up.

Do not invent a daily API cap to make a slide look finished. A cap is a number in your contract or a limit you can show in the runtime you already have. A workshop guess is not a cap. A blog is not a cap. If the quote includes a ceiling, attach the page it came from. If it does not, write "not stated" and price the retry design without a fictional limit. A design that only works under a made-up ceiling will fail on the first busy day, and the post-mortem will blame volume instead of the missing contract.

## What the bill is made of

Implementation cost means the parts of the bill. It is not a dollar figure, and this page will not invent one. A quote you can compare separates the parts so you argue about scope.

Discovery names the systems, the events, and the owner of each source. A single workshop with no system list is not discovery. You will pay for the list later, during build, when a missing system becomes a change request. Ask for the list in the quote. If a system is unknown, the line should say unknown, not a rounded guess.

Connection design names the API or the event, the Salesforce object, the external id, and the write when the key already exists. Update, ignore, and fail are different pieces of work. The word upsert without a key is a duplicate factory. Put the key on the page. A seller should be able to read which field joins an SAP order to an account without opening the flow.

Error handling is a queue, a person, and a replay. A flow that emails a shared mailbox and then drops the message has chosen a design. It may be the wrong one. Write the choice down. Include what "down for an hour" means for the seller on the phone. Include who is allowed to replay a message after the source has corrected it. A replay that creates a second order is more expensive than the original failure.

Environments are the MuleSoft runtime, the Salesforce sandbox it targets, and the promotion path. A quote that builds only against production is a quote that tests on the business. Testing names one payload that must succeed and one that must fail. Include a duplicate key. Include the source being unavailable. Include a field the seller must not see, and show that the integration user cannot write it.

Cutover is the hour the flow starts, who watches the queue, and how you stop the flow without a deploy panic. Hypercare is the following days with a named owner, not a rota that says "the team". Training is who can read an error without calling the partner. Leave any of these off the quote and the number you were given is a deposit, not the cost.

| Line on the quote | What you are buying | Send it back if |
| --- | --- | --- |
| Discovery | Systems, events, source owners | The list is "SAP and Salesforce" and nothing else |
| Connection | Object, external id, write rule | The key is missing or described as flexible |
| Failures | Queue, named reader, replay | Failures go to a mailbox and then vanish |
| Environments | MuleSoft runtime plus a Salesforce sandbox | The sandbox is said to include MuleSoft |
| Test | One success and one forced failure | Testing is a single word |
| Cutover | Start, watch, stop | The only plan is to turn it on |

## The test a buyer should use

Searches ask for the best MuleSoft Salesforce integration agency, for a consultant to hire, and for an implementation partner. A ranking will not survive your SAP system. Use a test in the room.

Ask the partner to draw three boxes on one page. The system of record. MuleSoft. Salesforce. One event on each arrow. The external id under the drawing. Under that, what happens when the source is down for an hour. A partner who can do this has started. A partner who answers with a logo slide has not. Do the drawing before you compare day rates. Two precise drawings can be compared. Two slogans cannot.

Ask what the sandbox contains on the first morning of build. The sound answer is a Salesforce sandbox and a separate MuleSoft environment, wired for the test. The unsound answer is that the sandbox includes MuleSoft, or that production will do as a build target because the sandbox is busy. Busy is a scheduling problem. Building in production is a different risk, and it should be refused in writing.

Ask them to refuse a daily cap they cannot show. A partner who invents a number to sound precise will invent scope the same way. You want the person who writes "not in the contract" and still prices a retry. Ask who owns the queue after go-live. A name, written into the runbook, not a shared inbox. If the name is missing, the quote is unfinished. Hiring a consultant is this conversation. It is not a position in a directory.

Do not accept a claim that any firm is the best, including the firm publishing this page. The drawing is the test. If two firms draw the same picture, compare the error path and the named owner. If neither can draw it, you are not ready to sign. A reference call is useful after the drawing, not instead of it. Ask the reference which failure they hit in the first month, and whether the queue had a name on it.

## What you settle before the first message

Write five lines before anyone builds. The system that owns the order. The event that may create or update a Salesforce record. The field that is the key. The integration user that performs the write, and the fields that user must not touch. The person who reads the failure queue on a weekday morning.

Then run one successful message and one failed message, with MuleSoft pointed at the sandbox on purpose. Read the Salesforce record as the seller who will use it. If that seller sees a cost field they are not meant to see, field-level security is wrong. The flow is not the place to hide it. Fix the permission set before volume arrives. An instruction in a mapping document does not close a field the user can query.

Keep Data 360 off this drawing unless it has its own sentence and its own owner. [Informatica's catalogue and master data work](/informatica-data-360) is another acquisition and another job.

:::warn
A spreadsheet import is not a MuleSoft implementation. A Salesforce sandbox does not contain MuleSoft. A daily API cap you cannot point to in the contract is not a requirement. Strike it from the quote and price the retry you can actually run.
:::

The quote is ready when a new administrator can see the systems, the key, the failure path, and the owner without asking the partner who sold the work.

## The other searches

The project quote is on [mulesoft implementation cost](/mulesoft-salesforce-implementation-cost). That page does not print a figure. Who bought the company is on [what happened to mulesoft](/what-happened-to-mulesoft). The connector is on [integrating mulesoft with Salesforce](/integrating-mulesoft-with-salesforce). Whether to move is on [should I migrate from mulesoft](/should-i-migrate-from-mulesoft). The customer fee is on [mulesoft licence cost](/mulesoft-salesforce-licence-cost). Who to hire is on [hiring for mulesoft](/hire-mulesoft-salesforce-partner). This page does not rank an agency.


## Questions

### Does a Salesforce sandbox include MuleSoft?

No. A sandbox copies Salesforce metadata and, depending on type, CRM data. It does not include a MuleSoft runtime, and a refresh does not deploy an API or replay messages. You point a separate MuleSoft environment at that sandbox on purpose. If a proposal says the sandbox already includes MuleSoft, ask to be shown the flow. The absence is the answer, and the runtime belongs on the quote as its own line.

### Is a MuleSoft project a data migration into Salesforce?

Only if someone has misnamed a copy. MuleSoft was acquired in 2018 and kept its name. It is an integration platform. Agreed messages create or update records. The other system can remain the owner. A full extract of every table into custom objects is a paste. Ask for the event, the object, and the external id. If those three are missing, you are not looking at an implementation yet.

### What should a MuleSoft Salesforce implementation quote list?

The parts of the bill, not a single unexplained number. Discovery of systems and source owners. Connection design with the key and the write rule. A failure queue with a named reader and a replay. Environments, including a MuleSoft runtime that the sandbox does not contain. A test that succeeds and a test that fails. Cutover, a way to stop, and hypercare with a name. Leave one out and the figure is a deposit.

### Is Data 360 the same product as MuleSoft?

No. They are different products. Salesforce states: the Data Cloud name became Data 360 on 14 October 2025. That rename does not mention MuleSoft and does not turn an integration flow into a Data 360 pipeline. If both are in the programme, write one sentence for each job. If the sentences match, you have one job wearing two names. Do not buy a second logo to decorate the first picture.

### How do we choose a MuleSoft Salesforce partner?

Use a test, not a ranking. Ask for three boxes on one page: system of record, MuleSoft, and Salesforce, with one event on each arrow and the external id written underneath. Ask what happens when the source is down for an hour. Ask the partner to refuse any daily API cap they cannot show in your contract. Ask for the name that reads the failure queue after go-live. No firm is the best by announcement. The drawing is the comparison.

### Is mulesoft owned by Salesforce?

Yes. Salesforce bought MuleSoft in 2018. It kept the name. The full account is at https://synconai.com/what-happened-to-mulesoft.

### When did Salesforce acquire mulesoft?

2018.

### What happened to mulesoft after the Salesforce acquisition?

MuleSoft is an integration platform. It is not Data 360, and a Salesforce sandbox does not include it.

### Should I migrate from mulesoft to Salesforce?

An integration is a contract, an error path, and a system of record. Copying rows into Salesforce and calling it MuleSoft is the wrong job.

### What is the mulesoft licence cost, or the price Salesforce paid?

The page this guide cites does not publish a MuleSoft purchase price or a licence fee. The licence read is at https://synconai.com/mulesoft-salesforce-licence-cost.

---

SynconAI is a Salesforce Select Partner and an OpenAI Select Partner, delivering architect-led Salesforce and AI programmes across the United States and Australia. Related service: Integration (https://synconai.com/salesforce-integration-services).