ChatGPT
Claude
Google AI
Copilot
A data council voted to retire the old master-data tool on the Monday after the close. Informatica would replace Data 360. Identity resolution would become the golden record. Zero copy would mean the warehouse was, in effect, already inside Salesforce and fast enough for the call centre. Around the table everyone already agreed the close had cleaned the data. On Tuesday a seller updated a phone number on the account. The unified profile still showed the old number from a second system. Someone overwrote the account with the profile, because they had been told the profile wins. The source still had the number the customer had confirmed that morning. By Thursday three systems disagreed, and the call centre read the wrong one. The agreement is the problem. It is easy to reach, and it fits one box on a slide, which is not an attribute anyone owns.
A wrong phone is compatible with an account field the org already stores, a profile that relates sources and does not override them, a federation that is not a speed promise, and a completion that did not transfer trust. Only one of those is a decision about a named attribute. The close had been used as a merge. It was not a merge.
What follows are the questions that separate those explanations. Each has a good answer and a bad answer, and the difference is whether the answer names something specific: an attribute, a system, a field, a person who may not overwrite it. A general answer at this stage is what turns into Thursday's disagreement.
| Question | Who has to answer it | What a bad answer usually means |
|---|---|---|
| 1. Which attribute is in dispute | The person who can point at the phone, the legal name, or the billing address | "Master data" is standing in for a value |
| 2. Which system may change it | Finance, or whoever already owns that attribute | The close is being treated as a transfer of trust |
| 3. What do the account and the profile already do | The administrator who can open the account, and whoever runs identity resolution | "The profile wins" is about to overwrite a source |
| 4. What does zero copy mean here | Whoever promised the call centre a speed | Federation is being read as a latency promise |
| 5. What must the plan refuse | Whoever drew one box for two products | A second master is being called a cleanup |
1. Which attribute is actually in the room?
The question is not whether to migrate Informatica. It is the phone, the legal name, the billing address, or another value a person can point at, and the system that owns it.
A good answer sounds like one attribute, the system that may change it, the systems that may display it, and the systems that must not overwrite it, written by the person who owns that attribute.
A bad answer sounds like master data, or Informatica, or Data 360. If you cannot name the attribute and the system that owns it, you are not ready to migrate. You are ready to stop saying the close cleaned the data. A programme that starts by deleting a product has chosen the Thursday disagreement. Send it back.
Salesforce completed the Informatica acquisition on 18 November 2025. 18 November 2025 is a completion. It is not a golden record. Stay when a system already owns the attribute and people trust it. The close did not transfer that trust. Moving "the billing address, owned by finance, shown on the account, not written back by the profile" might be a decision. Moving "master data" is not.
2. What did the close actually bring?
The press page states what the close brings, and the sentence is quoted once: "The close of the acquisition brings Informatica’s rich data catalog, integration, governance, quality and privacy, metadata management, and Master Data Management (MDM) services to the Salesforce platform."
Read it as the list of services the sentence names: a data catalogue, integration, governance, quality and privacy, metadata management, and master data management. The sentence does not say those services replace Data 360. It does not say a unified profile overwrites an account. It does not promise a speed. It does not name your phone field. Do not rewrite it.
A good answer sounds like the services left as a list beside Data 360, not instead of it, written by the person who wanted one box.
A bad answer sounds like Data 360 is finished. Informatica does not replace Data 360. The services named in the cited sentence are not the same claim. Quote the sentence. Then give each attribute an owner in your own words. If the owner is blank, the migration is a slogan.
Data 360 is a different product. The help page says only this about the name, quoted once: "As of October 14, 2025, Data Cloud has been rebranded to Data 360."
Use that sentence to correct a label. On 14 October 2025 Data Cloud took the name Data 360. The sentence does not mention Informatica. It does not revise 18 November 2025. Put the rename on the Data 360 line. Put the close on the Informatica line. If a diagram has one box, the diagram is the defect. Do not migrate because Data Cloud was renamed. The rename is a label. It does not make Informatica and Data 360 the same box. A second master beside the one you already run is a second argument, not a cleanup.
There is no end date for Informatica in the material this decision is allowed to use, and there is no end date for Data 360 either. Do not invent either.
3. What do the account and the profile already do?
Name the native behaviour before you compare a master-data tool with it. An Account is a record in the org. It stores the fields your administrators named: the name, the phone, the address, and whatever else you capture there. A user who can edit the account can change those fields. A report can filter them. The account does not, by existing, look at a second system and decide which phone is true. It stores the value someone last wrote, under the access you configured. That is what the account already does.
Identity resolution, on Data 360, is the other behaviour you must name before the comparison. It generates a unified profile from source profiles. The profile helps you see that two sources may be the same person. It is not a golden record. It does not override source values. It does not pick a winning phone and stamp it onto every source. If you have not said that out loud, you are not ready to compare. You are ready to stop calling the profile the master.
A good answer sounds like the field on the account, the source that owns the value, and a statement that identity resolution may link profiles without writing back, given by someone who has seen both the account and the profile.
A bad answer sounds like the profile wins. Strike that line. It is the Thursday incident. If the need is "show the phone we already store on the account", you may not be migrating. The account already has the phone. Leave both products out of that sentence. If the need is "decide which of two phones is official", neither the profile nor a rename will decide it. A person names the owning system. You do not get that decision for free by retiring one of the products. Keep both until each attribute has an owner.
4. What is zero copy allowed to mean?
Zero copy is the third behaviour to name, and then to limit. Zero copy is federation. The data stays where it is and is read from there. Federation means you did not make a second copy as the price of the read. It is not a latency promise. It does not say the call centre will see a warehouse change before the sentence ends. It does not say the account field updated itself.
A good answer sounds like the word federation, written by the person who promised a speed, with any tested time omitted unless that person has actually measured one.
A bad answer sounds like fast enough for the call centre, with no measurement. Write "federation" if you mean federation. A tested time is written only if you have measured one. No time is invented here. Do not migrate a warehouse into Data 360 because someone called federation a live copy. A seller who needs a value on the account needs a field and a rule, not a slogan about speed.
Open the attribute and write four lines. The field on the account, if there is one. The source that owns the value. Whether identity resolution may link profiles without writing back. What zero copy is allowed to mean, which is federation, not a speed. If a meeting treats the profile as the new official customer and deletes the source, the meeting invented a behaviour the product does not have.
5. What is the plan using instead of the attribute?
A good answer sounds like a refusal, written by the owner of the attribute, of four things: one box for two products, a golden record, a latency promise, and a ranked listing.
A bad answer sounds like a listing, or a shortlist with a winner. No listing is invented here. A catalogue of master-data tools is not described as a decision. If a proposal cites a listing that was never named here, ask which attribute it owns and which systems it must not overwrite. Until they can, the listing is a rumour. The shapes here are not ranked. Keep the current master for an attribute it already owns. Use the account field you already store when that field is the value people trust. Split by attribute, in writing, when two systems must not pretend to be the same record. Firms are not ranked. Listings are not ranked. Two options can be compared by which phone the call centre reads on Thursday. A league table cannot.
Do not collapse two products because one close date appeared on a slide. Stop after one attribute. The next attribute is the next decision. If you cannot cross the others out, you are collecting scope.
What staying actually looks like
All five answers are measured against an alternative, and the alternative is usually left unstated, which flatters the single box.
State it. Staying means a named system remains the master for a named attribute, the account shows the field you already store, and the profile relates sources without writing back. The cost of a false move is the week you already had: the seller's new number overwritten by an old profile, three systems in disagreement, and the call centre on the wrong one.
There is a version of staying that is simply the correct decision. If nobody can name the owning system, retiring a product will not create one. An organisation that writes the attribute first reaches any later design with the source value still intact.
A good answer sounds like the attribute, the owning system, the account field, a line that identity resolution will not override sources, and the word federation where zero copy was promised, with a date and a person who will check the phone the call centre reads.
A bad answer sounds like we cannot keep two data products after the close. The close put services beside Data 360. It did not make them the same box.
Where the neighbouring questions live
Cost and hiring sit on the Informatica implementation page. The purchase story sits on what happened to Informatica. The connector sits on integrating Informatica with Salesforce.
