Integrating Informatica with Salesforce: it does not replace Data 360

A match job overwrote the phone number on the contact. The warehouse file had a different number, and the job treated the match as a golden record, so one value survived and the source value did not. The same note said zero copy would put the warehouse number on the seller's screen at once, so nobody kept a local copy. The screen was late. The seller called the old number, which was the one the contact still trusted, and which the job had already replaced. Data 360 was on a list to be switched off because Informatica had closed. Nothing in the close had asked for the overwrite or the switch-off. The call had landed as a winning value. That is the failure.

That Monday is the integration this page is about. Salesforce completed the Informatica acquisition on 18 November 2025. Informatica does not replace Data 360. Identity resolution is not a golden record and does not override source values. Zero copy is federation, not a latency promise. Name the system that owns each value, the object or attribute the call may touch, and the failure when the call does not land, including a land that overwrites. A diagram that skips those is a poster. The build sits on the Informatica implementation page. The ownership story sits on what happened to Informatica. This page is the value that must not be overwritten.

#The system

This page quotes the close 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 the list as the release's list. Catalogue, integration, governance, quality, privacy, metadata, and master data management. The sentence says those services come to the Salesforce platform. It does not say Informatica replaces Data 360. It does not say identity resolution writes a golden record. It does not say zero copy is instant. It does not publish your fee.

Data Cloud had already been renamed. This page quotes that sentence once: "As of October 14, 2025, Data Cloud has been rebranded to Data 360." Data 360 is the name from 14 October 2025. Informatica's completion is 18 November 2025. Two dates, two products. A diagram that deletes Data 360 on the November date has used a later acquisition as a rename of an earlier one. Put each date on its own line. If both products are in the programme, write one sentence for the data set Data 360 holds and one sentence for the catalogue, the quality rule, or the master-data job Informatica holds. If the sentences match, you have one job wearing two names.

Name the system that owns the attribute. The warehouse may own the ship-to phone. The contact in Salesforce may own the phone the seller is allowed to call. Those can both be true. Informatica does not become the owner because the close listed master data management. Master data management on the release list is a service the close brings. It is not a permission to pick a winner. Write the owner's name next to the attribute before you connect anything. A second MDM beside the one you already run is a second argument, not a cleanup.

This page will not invent an API name, a middleware SKU, or a price. The cited pages do not publish a licence fee. Do not paste a deal figure from memory into the integration cost. This page does not give Informatica an end date. The completion was not a shutdown, and it was not a shutdown of Data 360.

#The object

The object is the attribute, on a record you name, owned by a system you name. Phone on Contact, with the warehouse named as a source that must not overwrite it, is a fair example. "The customer" is not an object. "Golden record" is not an object. If the design cannot say which field is allowed to change, it is not ready to match.

Identity resolution is not a golden record and does not override source values. A unified profile is not a surviving row that replaces the sources. The sources keep their values. A job that picks a winning phone number and writes it back over the contact has left identity resolution and started an overwrite. Do not brief that overwrite as what the product does. If you need a call number for sellers, name the field they may dial, and name the system that is allowed to change it. The other numbers stay on their sources, readable, not deleted by the match.

Catalogue, quality, privacy, and metadata are different objects again. A catalogue entry that describes a table is not the contact. A quality rule that flags a blank phone is not a permission to fill the blank from another system. Privacy that says a value must not be copied is a refusal, and the integration has to be able to honour it. Write the refusal next to the attribute. A match that copies a value privacy has refused is the failure, even when the match looks confident.

Do not let MDM on the release list become a custom object called Golden Customer. That object will be fed by overwrites and will disagree with every source within a week. If you already have a place sellers edit the phone, that place remains the object. Informatica can describe it, check it, and refuse a bad load. It does not replace it because a sentence listed master data management.

#The failure when the call does not land

The call fails in two ways you must not confuse. It does not land: the source is unreachable, the match does not run, the seller's screen does not show the federated value. Or it lands badly: it overrides a source value, copies a value privacy refused, or switches Data 360 off because a date arrived. Write both if both can happen. Do not collapse them into "data quality".

Zero copy is federation, not a latency promise. Federation means the value can be read from where it already lives, without a copy you then have to reconcile. It does not mean the screen is instant, and it does not mean the call cannot fail. When the federated read does not land, the seller needs a rule. They use the value on the record they are allowed to trust, and they say the other system did not answer. They do not type the warehouse number onto the contact to "complete the zero copy". That typing is the overwrite, done by hand.

Do not invent a millisecond, a daily cap, or a freshness guarantee. This page states no latency number. A slide that says zero copy is real time has added a promise the design does not have. Strike the promise. Describe what the seller does when the read is late or absent. That sentence is the failure plan.

An overwrite that has already happened is a different recovery. You need the source value, still held at the source because identity resolution does not override it, and a person who may put the contact back if a job wrote over it anyway. If your job does write over sources, you have built something else. Name it as a write, with a field and a test, not as identity resolution.

#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. One cloud labelled Informatica and Data 360, with an arrow into a golden record, does not say who owns the phone, which field may change, or what the seller does when the federated read does not land. Draw the source. Draw the attribute. Draw the failure. If the failure box says "golden record", replace it. Identity resolution is not a golden record.

Do not draw zero copy as a stopwatch. Draw it as a read from the system that already holds the value, and draw the miss. A poster with the words real time is a latency promise. This page will not back it.

Keep Data 360 on its own box if it is in the programme. The October rename and the November close are not one event. A box that deletes Data 360 has used Informatica as a replacement. The release list does not say that.

#What you settle before anyone matches a record

Write five lines before a match runs. The attribute. The system that owns it. Whether any job may write that field. What identity resolution is not allowed to do, in the words above. What the seller does when a federated read does not land.

Then say what you are not buying. You are not buying a replacement for Data 360. You are not buying a golden record. You are not buying a latency promise. You are not buying a price this page does not state. You are not buying an end date. Leave Data 360 in place until its own sentence says otherwise, and that sentence is not the Informatica close.

The implementation page is where the system of record per attribute is taken apart. What happened to Informatica is where 18 November 2025, the release list, and the refusal to treat the close as a Data 360 shutdown are kept. Use those pages when the meeting argues about the acquisition. Bring the meeting back to the phone number.

Agree who may add an attribute to the match. A new field is a new owner and a new refusal. The poster does not grow a golden record to hold it.

#A test you can run

Take one contact whose phone you can explain. Run the match in a place that is not production, or run it so that it cannot write. Confirm the source value is still the source value. Confirm the contact's phone did not change unless you named that field as writable by a job that is not identity resolution. If the phone changed, you have an overwrite. Stop and name it.

Then withhold the federated source. Open the screen the seller uses. The rule you wrote should be sayable: which number they call, and the fact that the other system did not answer. If the screen is blank and the script says "it is real time, wait", the test failed. You briefed a latency promise.

Confirm Data 360 is still the product you named it as, if you use it. The November date is not a switch-off. If a runbook archives it on 18 November 2025, correct the runbook before you correct the match.

The integration is ready when a new architect can see the attribute, the owner, and the miss without drawing a golden record. If the page still picks a winning phone, send it back. The close on 18 November 2025 brought a list of services. It did not overwrite the contact for you.