Integrating MuleSoft with Salesforce: name the system, the object, and the failure

The warehouse sent an order at 06:10. At 06:11 the Salesforce order was not there. The seller on the early call promised a ship date from a spreadsheet that finance had mailed the night before. The architecture slide on the wall showed one box. The label read MuleSoft, Data 360, and Salesforce, with arrows in both directions and no object name. The failure from 06:10 sat in a shared mailbox. Nobody opened it before the forecast meeting. By 09:30 the customer had the date, the order still did not exist, and two people were arguing about whether the acquisition had folded MuleSoft into Data 360. The call had not landed. The meeting could not say where it was supposed to land.

That morning is the integration this page is about. MuleSoft was acquired in 2018 and kept its name. It is an integration platform. It is not Data 360. A flow needs a named system, a named object, and the failure when the call does not land. A diagram that skips those three is a poster. Do not promise a connector for every system you might one day attach. The build sits on the MuleSoft implementation page. The ownership story sits on what happened to MuleSoft. This page is the call.

#The system

MuleSoft was acquired in 2018 and kept its name. You still ask for it by that name. It carries an agreed message from a system you name. Salesforce can be the place a seller reads the result. The other system can remain the owner of the order. The acquisition did not turn every neighbouring system into a Salesforce object, and it did not turn MuleSoft into a second CRM.

People mix the name into Data 360 because both sit near the word data. They are different products. The help page this guide cites states a rename, and this page quotes it once: "As of October 14, 2025, Data Cloud has been rebranded to Data 360." Use that sentence to correct a label. It does not mention MuleSoft. It does not say an integration flow became a Data 360 pipeline. It does not say the 2018 deal was revised on 14 October 2025. Put Data 360 on its own line. Leave MuleSoft on the 2018 line, with the name it kept.

Name the system this flow talks to. Write the name a person in that team would recognise: the warehouse, the bank, the shop, the finance ledger. "External systems" is not a name. A logo is not a name. If the design lists five systems and describes none of them, you do not have five integrations. You have a poster with five logos. Start with one system, one direction, and one owner on that side. Add the next system only after the first call lands and the first failure has a reader.

Do not promise a connector for every system. Buying MuleSoft does not mean a ready path exists for each application in the estate. A partner who says the platform connects to anything, and then cannot name the system on this project, is selling a catalogue. Ask which system, which event, and who owns that system when it is down. If the answer is a product family rather than a system, send the page back. This page will not invent a connector name, a middleware edition, or a daily cap. None of those appear in the sentence this guide cites.

A Salesforce sandbox does not clone MuleSoft. Refreshing the sandbox copies Salesforce metadata and, depending on the type, some CRM data. It does not copy the runtime. It does not replay yesterday's messages. It does not keep the credentials that production used. You point a separate MuleSoft environment at that sandbox on purpose. Anyone who says the sandbox already includes MuleSoft should open it and show the flow. The absence is the finding. The same boundary is why a sandbox does not stand in for a system that lives outside Salesforce. The warehouse does not appear because the org was refreshed.

#The object

The call is allowed to touch one Salesforce object until you have written a second. Name it. Order is a fair example when the warehouse owns orders and a seller must see a subset. Account is a fair example when the message is a customer key and nothing else. A custom object is allowed when you can say who reads it and which report uses it. "Data" is not an object. A spreadsheet tab is not an object. If the design says the message updates Salesforce, ask which object, on which record, matched by which field.

Write the field that joins the two sides. The warehouse has a number. Salesforce must store that number on the object you named, in a field a person can point at. Create, update, and refuse are different behaviours when that number already exists. Pick one and write it down. A design that says the platform will work it out will create a second order on a busy morning and call it a success. The seller then has two ship dates. The customer has one.

Write the fields the call may change, and the fields it must not change. A cost, a margin, or a credit hold might live on the source and must not be writable by the integration user. Field access is the control. A note in a mapping document does not hide a field the user can query. Read the record as the seller who will use it. If they can see a figure they are not meant to see, stop and fix the permission before you add volume.

The object has an owner inside the CRM as well. Someone can refuse a field. Someone can say the order must not be created until a hold is clear. The integration team cannot invent that rule during an incident. Name the owner while the design is still a draft. Salesforce owning MuleSoft does not decide which object your order uses. Your design does.

#The failure when the call does not land

The call does not land for ordinary reasons. The source is down. The object is missing in the sandbox you just refreshed. The key already exists and the rule was never chosen. The credentials belong to a person who has left. The message reached a different org because the runtime was still pointed at production. Each of those is a different failure. Write the one you will actually meet, in a sentence a seller understands: the order is not on the account, and here is who is told.

A shared mailbox is not that sentence. Mail arrives, the thread grows, and the order is still missing. A failure needs a queue, a named reader on a weekday morning, and a way to replay that does not create a second record. Write the name. "The team" is not a name. If the reader is on leave, write the deputy. A flow with no reader is a flow that fails in private.

Say what the seller does while the call is down. They may read the last successful order and say so. They may stop promising a date. They may not type the order into Salesforce by hand and then let the replay type it again. The manual path is part of the failure design. If you skip it, Tuesday's spreadsheet returns, which is how this story started.

Do not describe the failure as a Data 360 problem. A missed order message is not a profile that failed to unify. Do not describe it as a daily limit you have not been shown. This page states no call ceiling. A number you add to the slide to look finished is an invention. Price the retry you can run. Leave the ceiling blank until a contract shows it.

Stopping the flow is part of the failure plan. Someone must be able to halt the call without a scramble, and someone must be able to start it again after the source is healthy. Write both. A flow that can only be stopped by a person who built it will run through an incident because that person is asleep.

#A diagram that omits three names is a poster

A diagram that does not name the system, the object, and the failure is a poster. Logos, a cloud, and the word integration do not make it a design. Draw three labels a new administrator can read without a legend. The system of record. The Salesforce object. What happens when the call does not land, including the name of the reader.

If the drawing has a box for every system in the company, it is still a poster. You were not promised a connector for each of them. Cross out the systems this project will not call. Leave one arrow. Put the object under the arrow. Put the failure under that. A steering pack can carry the poster in an appendix if someone needs the estate view. The build follows the page with three names.

Do not put Data 360 in the same box as MuleSoft. The quoted sentence renames Data Cloud. It does not draw a pipe. If Data 360 is genuinely in the programme, give it a different sentence and a different owner. One sentence for the message MuleSoft may carry. One sentence for the data set Data 360 may hold. If the sentences match, you have one job wearing two names. Delete one until a seller can point at two different outcomes.

The same test applies to a middleware edition, an API product name, or a price. This page will not supply them. The cited sentence does not. A box labelled with a product you invented is a poster with a fictional SKU. Strike the label. Write the system you actually have.

#What you settle before the first call

Write five lines before anyone builds. The system that owns the record. The event that may create or update the Salesforce object. The field that joins the two sides. The fields the call must not change. The person who reads the failure on a weekday morning.

Then say what you are not buying. You are not buying a connector for every system. You are not buying a Data 360 pipeline under a MuleSoft label. You are not buying a sandbox that already contains the runtime. You are not buying a price this page does not state, and you are not buying an end date. This page does not give MuleSoft an end date. The 2018 acquisition was not a shutdown. Leave the product up until a written replacement exists for the messages it carries.

The implementation page is where the quote is taken apart: discovery, the key, the queue, the environments, and a test. What happened to MuleSoft is where the year, the name, and the refusal to invent a purchase price are kept. Do not paste those pages into this diagram to make it look complete. Use them when the meeting starts arguing about 2018 or about October 2025. Bring the meeting back to the order that did not land at 06:11.

Agree who may change the five lines after go-live. A new system is a new design, not a setting. A new object is a new design. A new failure reader is a name you write down the day the old reader leaves. The poster will not update itself.

#A test you can run

Point the MuleSoft environment at the Salesforce sandbox on purpose. Send one message that must create or update the object you named. Read the record as the seller. Confirm the key field matches the source. Confirm a field the seller must not see is closed.

Then force the failure. Stop the source, or send a key that already exists, and watch where the miss is recorded. The named reader should be able to say what happened without opening a slide. Replay once. Confirm you still have one record, not two. If the replay creates a duplicate, the rule was never chosen.

Refresh the sandbox only when you know the runtime will be re-pointed. A refresh that leaves the call aimed at the wrong org is an incident caused by a calendar. Write the re-pointing next to the refresh. Do not assume the clone brought MuleSoft with it. It did not.

The integration is ready when a new administrator can see the system, the object, the key, and the failure reader without asking the person who sold the work. If the page still says integration and names none of those, send it back. The acquisition in 2018 kept the name. It did not land Tuesday's order for you.