# 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. **Published:** 2026-03-05 **Canonical:** https://synconai.com/data-compliance-international-salesforce **Author:** SynconAI Architecture Team ## In short Separate Salesforce orgs can keep data apart. They do not, by themselves, make the estate compliant. For a record that crosses, know who the controller is, which region the data sits in, and which consent or other recorded basis travelled with it. A Hyperforce region is a location for the stack. It is not a privacy programme. This is an operating checklist for the platform, not a legal sign-off. ## 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. 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. - **About Salesforce Data 360** (retrieved 2025-10-14) https://help.salesforce.com/s/articleView?id=data.c360_a_data_cloud.htm&type=5 > 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. ## What to take away - A second org is a boundary. It is not evidence that you are compliant. - On a record that crosses, store the controller, the region, the purpose, and the consent. - A Hyperforce region says where a stack can run. It is not a privacy programme. - This page is an operating checklist. Counsel applies the law. Nothing here is a sign-off. ## The guide A 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. :::warn This page is an operating checklist for the platform. It is not a legal sign-off. Counsel applies the law. A region, a second org, or a product rename does not do that work, and a board pack should not say they did. ::: ## 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](https://help.salesforce.com/s/articleView?id=data.c360_a_data_cloud.htm&type=5) 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](/salesforce-center-of-excellence). 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. :::note Test one transfer and read it back. If the destination has the person and the email, and a blank where the basis was, fix the map. Do not open a second org to hide the blank. The second org will have it too. ::: 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. ## Questions ### Do separate Salesforce orgs make us compliant? They can keep data apart. That is a boundary, and it is useful when you can say what may cross it. You still need the region, the purpose, and the consent or other recorded basis on the record that crossed. Another org with those fields blank is a second copy of the same gap, and it will look like progress on a diagram. Do not open a new org to solve a blank map. Fix the map, then decide whether the boundary is still what you need. ### Is a Hyperforce region a privacy programme? No. A Hyperforce region says where a stack can run, and it does not name the controller, the purpose, or the consent that travelled with the record. Those have to be stored and readable after a sync. A location can be the right location and the row can still be unexplained. Treat the region as a location decision, build the fields and the counsel beside it, and do not put the checkbox on a slide in place of the four facts. ### What should a crossing carry? The purpose, and the consent or other basis your counsel told you to store, visible in the destination, along with who you believe the controller is and the region the data sits in. Test one transfer and read it back, including a row that should not have crossed. If the basis is blank, fix the map before you add another flow. A guessed basis looks finished and is harder to see than a blank. If counsel has not told you what to store, do not invent it on the integration. ### Is this page a legal sign-off? No. It is an operating checklist for the platform. Laws differ, and counsel applies them. A Data 360 rename is not a new legal position: Salesforce says the name changed and the functionality and content remains unchanged. A note that some features are licenced add-ons with usage limits is not a certification of your organisation. Do not translate a vendor page into a sentence that says you are compliant; show the four facts on a sample instead. ### What can we show if someone asks? For a recent sample of records that crossed: who you believe the controller is, the region the data sits in, the purpose, and the basis on the record. Include the flow that moved the most rows and a campaign flow, because that is where a map is most often skipped. A blank in that set is the work, ahead of any new org or any new region story. The person who approves a new crossing should see those fields before the flow runs, not in a reconstruction afterwards. --- 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: Salesforce consultancy (https://synconai.com/salesforce-consultancy).