How to manage data compliance across multiple international Salesforce instances
Another org does not make you compliant. You still need the region, the purpose, and the consent on the record that moved.
Platform & ArchitectureA campaign flow copies a list overnight. In the destination org the records have a name and an email. The purpose is blank. The consent field is blank. The basis counsel told you to store is blank. The board pack, already printed, says the estate is covered because the stack runs in a chosen region and because there is a second org. Neither sentence is on the record. The person who asks next month will not be answered by the pack. They will be answered by the blank.
Separate Salesforce orgs can keep one country's records from sitting in another country's org. That is a boundary. It is not a compliance programme. You still have to know, on the record that crossed or on a store you can join to it, who the controller is, where the data sits, why you hold it, and which consent or other recorded basis travelled with it. If those live in a policy PDF, they will not survive a sync. The sync copies fields. It does not copy a paragraph in a PDF nobody mapped.
Controller, region, purpose, consent
Write four facts where a transfer can be read back. Who you believe the controller is for that record. The region the data sits in. The purpose you are holding it for. The consent, or the other basis your counsel told you to record. This page will not tell you which basis is lawful. Laws differ by country, and counsel applies them. What the platform will not do is invent a purpose you forgot to store, or repair a basis the integration dropped.
Say, in the field, what each fact means in your org so two teams do not fill them differently. Controller is the party your counsel named, stored as an identifier a person can read, not as a slogan in a help article. Region is where that record's data sits, which may not be the region in the diagram if a copy has already moved. Purpose is the reason this record is held, specific enough that a later reader can see it is not "marketing" for every row a campaign happened to include. The basis is what counsel told you to record. If counsel has not told you, the field stays blank and the transfer does not run. A guessed basis is worse than a blank, because a blank is visible and a guess looks complete.
When a record crosses, the purpose and the basis have to be visible in the destination. Test a transfer. Read it back as someone who was not in the build. If the destination has the person and the email, and a blank where the basis was, the integration dropped the only facts a later question will need. Fix the field map before you open another org to solve privacy. Another org with the same blank is a second copy of the gap, and it will be described as progress because a diagram gained a box.
A population is not one record. The test has to include a row that should not have crossed: someone whose basis does not cover this purpose, someone in a country the flow was not written for, a test record that was never removed. If those rows arrive, the filter is the defect. A successful count of rows moved is not a successful transfer. The count you want is the count counsel's list allowed, and a sample you can open and explain.
A region is a location
A Hyperforce region is a statement about where a stack can run. It does not name the controller. It does not record consent. It does not choose a purpose. Treat a region checkbox as a location decision, made with the people who run the platform, and then build the privacy work beside it: the fields, the map, and the counsel. A location can be the right location and the record can still be unexplained. Do not put the region on a slide in place of the four facts. Do not describe the checkbox as a programme.
The same restraint applies to a second org. Separation is useful when the boundary is the point: this population stays here, that population stays there, and the list of what may cross is short and owned. Separation is not useful when the same integration copies the population you just separated, minus the fields that made the separation meaningful. Draw the boundary. Then draw the crossings. If you cannot draw the crossings, you do not know what the boundary is worth.
Who approves a new crossing is a name, not a default of "the project." A new flow, a new campaign, a new subscriber, is a new crossing until someone shows it is not. The approver sees the fields that will move, including purpose and basis, before the flow runs. After it runs, you are reconstructing. Reconstruction means asking people what they remember mapping, which is how a blank becomes permanent.
What the product pages are not
Data 360 help records a rename: "As of October 14, 2025, Data Cloud has been rebranded to Data 360. During this transition, you may see references to Data Cloud in our application and documentation. While the name is new, the functionality and content remains unchanged." A new name is not a new legal position. Update the diagrams so teams are not integrating to a label that has moved. Do not brief the rename as a change in your obligations, and do not delay the field map because the label is in transition. The fields are the work. The label is a sentence on the diagram.
The same help page says: "Some Data 360 features are offered as add-on licenses, and others have usage limitations, though many limits can be adjusted to meet your business needs." That is a licensing and limits statement. It is not a certification of your organisation, and it is not a finding that your transfers are sound. An add-on does not record consent. A limit that can be adjusted does not tell you the purpose of a row. If a vendor page does not say you are compliant, do not translate it into that sentence in your own pack. The pack can say where the stack runs, which org holds which population, and which four facts you can show on a sample. That is an operating claim. It is the one you can defend without borrowing a sentence the vendor did not write.
The sample you can actually show
Take records that crossed a border in the last quarter. For a sample, show the four facts. Controller. Region. Purpose. Consent or other recorded basis. If any of the four is blank, that blank is the work. Do it before the next integration, not after a request from a person whose record you cannot explain. Pick the sample from the flow that moved the most rows, and from a flow someone added for a campaign, because the campaign flow is the one most likely to have been built without the map.
Keep the orgs if you need the boundary. Document what is allowed to cross, who approves a new crossing, and how you will notice a flow that copies more than the list. Notice means a person looks before it runs, not a report after the quarter. A flow added for a campaign can move a population nobody reviewed. The centre, or the platform owner, sees that flow before it runs. That is the same front door as a centre that can refuse a flow before it copies. Compliance that starts after the copy is a reconstruction, and the reconstruction will be missing the basis the map never sent.
| Fact | On the record | A blank means |
|---|---|---|
| Controller | The party counsel named, readable on the row | You cannot say who the record is held for |
| Region | Where this data sits, not only where the diagram hoped | A copy may already be somewhere else |
| Purpose | Why this row is held, specific to the use | "Marketing" on every row a flow touched |
| Basis | What counsel told you to store | A guessed value that looks finished |
Read a sample against the table before you open another org, buy another region story, or rename a slide. The table is the checklist. Counsel decides what may be stored and what may move. This page does not.
Walk one crossing with the person who will be asked about it later, not with the person who built the flow. Open the destination row. Read the four facts aloud. If you have to leave the record to find the purpose in a slide, the purpose is not on the record. If the basis is a value nobody can explain, treat it as blank and say so. A sample of ten rows, including one that should not have moved, is enough to see whether the map holds. You do not need every row in the quarter to know the campaign flow dropped the field.
Write down what is allowed to cross as a list a new builder can read: which objects, which fields, which purposes, who approves an addition. A flow that copies "the account and related records" is not on that list until someone names the related records. Related is how a campaign acquires a population it was not shown. The approver's job is to reject that phrase and demand the fields. The centre sees the flow before it runs. After it runs, the sample is how you discover the phrase was allowed through. Do that sample on the flow that moved the most rows, not only on the careful one you are proud of. The careful flow will pass. The campaign flow is the one that copied "related records" and left the basis behind. If you only read the careful flow, you will brief the board on the wrong map.
Cheap, before the next campaign flow: the four fields, a test row that should not cross, a named approver for a new crossing, and a sample from last quarter with the blanks listed.
Expensive, after a population has moved with the basis missing: explaining a record you cannot join back to a purpose, in every org the flow touched. Another region checkbox will not fill the field. The field map will. Do that before the flow runs again.



