# How to test multi-cloud integrations in a Salesforce sandbox environment A full sandbox copies the CRM org. It does not copy Marketing Cloud or the production Data 360 tenant. Test named non-production endpoints, and write down what was missing. **Published:** 2026-02-20 **Canonical:** https://synconai.com/test-multi-cloud-integrations-sandbox **Author:** SynconAI Architecture Team ## In short A full Salesforce sandbox copies the CRM org. It does not copy Marketing Cloud, and it does not copy your production Data 360 tenant, the way it copies Sales Cloud. Test against named non-production endpoints. Write down what the sandbox did not copy, and do not treat a missing Marketing Cloud or Data 360 tenant as a successful test. ## 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 > Connect data using zero copy data federation. ## What to take away - A full sandbox copies the CRM org. It is not a free copy of Marketing Cloud or of the production Data 360 tenant. - After every refresh, write what came across and what did not. A blank line is a gap, not a pass. - Point every connector at a named non-production endpoint, including any Data 360 connection. - Zero copy federation that still points at production is a production read. Disconnect it or point it somewhere else, and say so on the list. ## The guide A Salesforce sandbox copies the CRM org. A full sandbox is the wide copy: metadata and CRM data, enough to rehearse Sales Cloud and the other CRM clouds that live in that org. It does not give you a free copy of Marketing Cloud. It does not give you a free copy of the production Data 360 tenant. Treating a refresh as if those had come along is how a test goes green against nothing. The failure is a green run that touched production. The CRM sandbox was refreshed on Friday. On Monday a tester checks a journey. The connector still has the production Marketing Cloud endpoint, because the refresh copied the CRM configuration and the endpoint is a URL somebody pasted, not a thing the sandbox knows how to rewrite. The test send leaves. A real subscriber gets a message from a rehearsal. The log in the sandbox looks successful. The other log, in production, is the one that mattered, and nobody had a line on the list that said which tenant the call would hit. A blank line was treated as a pass. Data Cloud was renamed Data 360 on 14 October 2025. You may still see the old name in the product and the documentation. Salesforce says the functionality is unchanged. The rename does not change the testing fact. The production Data 360 tenant is not a by-product of refreshing a CRM sandbox. A query from the sandbox against that tenant, "just to see real data", is a production read. It is not a test. ## Write down what you do not have After each refresh, write a list with the sandbox name and the date. On it: which CRM data came across, which integrations still point somewhere else, and which systems were not copied. Give Marketing Cloud Engagement, Account Engagement, and Marketing Cloud Next their own lines. Give Data 360 its own line. A blank line is not a pass. It is a gap you have agreed to remember. Marketing Cloud Engagement is a separate tenant from the CRM org. Account Engagement is its own product. Marketing Cloud Next is not those two, and a refreshed Sales Cloud org is still not a copy of it. If you have a non-production tenant for the product you actually use, write its name. If you do not, write that you do not. Do not test a send, a consent change, or a journey against production because the CRM sandbox happened to be free. The decision about which product you are integrating, and who owns consent, is in [Sales Cloud and Marketing Cloud](/integrate-sales-cloud-marketing-cloud). The sandbox list is where that decision becomes a named endpoint, or an honest gap. Refresh again, and write the list again. Sandboxes are refreshed because the CRM data went stale. The refresh does not preserve your careful repointing unless someone made it part of the refresh steps. A URL that was correct last month is a production URL this month if the refresh restored the metadata from production. The list is dated because the list expires. An undated list is how Monday's test uses Friday's assumptions after a Saturday refresh nobody told the testers about. The list lives where the tester can open it without asking. A page in the project space, the sandbox name in the title, the date at the top. If a colleague cannot tell, from that page, whether this sandbox can touch production, the page is not finished. "Ask Sam" is not a line on the list. Sam is not an endpoint. ## Named non-production endpoints Every connector in the sandbox points at a named non-production endpoint. The ERP, the billing system, the marketing tenant, the identity provider. The name goes on the list, next to the address you are actually calling. "We think it is the test one" is not a name. Open the configuration and read the host. Paste the host onto the list. If the host is production, change it or disconnect it before anyone calls the sandbox safe. Data 360 connections follow the same rule. Salesforce tells you to connect data using zero copy data federation. A federation, or any other connection, that still points at production is a production read, even while the CRM session is a sandbox. Point it at a non-production source, or leave it disconnected and write "not connected" on the list. Do not invent a setting name to cover the gap. The list is the control. Zero copy feels safe because you are "only reading". A read of a production customer, from a sandbox a contractor can log into, is still that customer's data leaving the production boundary. It is also a load on the production source. Who notices that read is the same question as any other integration pattern: if the failure, or the access, shows up only when someone happens to look, it has already happened. The catalogue of those patterns, and the condition that rules a live read out, is in [Salesforce integration architecture patterns](/insights/salesforce-integration-architecture-patterns). For a sandbox, the ruling-out condition is simple. If the far side is production, the pattern is not a test. ::: warn A CRM session in a sandbox does not make the call a test. If the endpoint, the federation, or the query target is production, you are in production. Disconnect it or point it at a named non-production system, and write the result on the list. ::: Check the named integration user, not only the URL. A sandbox copy of a credential can still be the production credential if someone pasted it into a named credential and the refresh brought it across. Read the credential's endpoint. Rotate or replace anything that can authenticate to production. A URL that looks like test, with a secret that opens production, is a production call. The list has a line for the credential as well as the host. ## What a fair test is A fair test uses the sandbox user, the sandbox endpoint, and only the data the list says you have. Include one deliberate failure: a bad payload that lands on a queue, is read by a person, and is replayed or rejected. Include one permission check as the integration user, not as a system administrator. Both belong in the notes. A test that passes only as an administrator has not tested the integration. It has tested the administrator. The deliberate failure is how you learn whether the sandbox is lying to you by omission. Send a payload with a missing identifier. The row should appear on the queue you claim exists. If the channel stays green and the row never arrives, the test environment has the same blind spot production will have, and you have just paid to see it before a customer does. Record the result. A project that only keeps the happy path will ship the blind spot. It does not include a live send from a production Marketing Cloud tenant, a write into the production ERP, or a query against the production Data 360 tenant just to see real data. Those are production changes. If the list says a system was not copied, the honest result for that system is that you did not test it. Ship the CRM test. Book the other test for the day the non-production endpoint exists. A green sandbox that never touched the other cloud is a CRM result. Report it as that. Say the gap in the release note in plain words. "Sales Cloud path tested in the full sandbox on this date. Marketing Cloud Engagement not tested: no non-production tenant. Data 360 not tested: federation disconnected." That paragraph is a successful report. A paragraph that says the integration was tested, when two of the three systems were absent, is how the production send happens later and everyone is surprised. The surprise was written down. It was written down as a pass. ## After the refresh, before anyone tests The order is the control. Refresh. Write the list the same day, including what did not come across. Repoint or disconnect every connector, and read the hosts back. Run the bad payload and the integration-user check. Only then invite the rest of the team in. A sandbox that is "ready" before the list exists will be used, because people are waiting, and waiting people will hit whatever endpoint is still in the configuration. When the non-production tenant arrives later, add its name to the list and run the test you deferred. Do not backfill the earlier result. The earlier result remains a CRM result. Pretending it covered the journey, because the tenant exists now, rewrites the evidence. The date on the list is what stops that rewrite. Keep the old page. Start a new one. ## Who gets this wrong Three people, and each one is acting reasonably. The person who refreshes the sandbox wants current CRM data, and the refresh restores metadata, including endpoints, from production. They did not mean to point the journey at a real tenant. The metadata did it. The list, written the same day, is the only thing that catches the restoration. A refresh with no same-day list is an unverified production path. The person who pastes a URL wants the test to be realistic. Production is realistic. That is why it is banned. Realism is not the goal of a sandbox. Isolation is. A realistic test against a named non-production tenant is allowed to be smaller, older, and less flattering. A flattering test against production is a send. If the non-production tenant is empty, say the test could not be run. Do not fill the gap with live subscribers. The tester who asks to see real Data 360 rows is trying to avoid a false pass on empty data. The instinct is sound. The method is not. Empty data is a reason to record that Data 360 was not tested. It is not a reason to federate to the production tenant for an afternoon. An afternoon is long enough for a contractor's login to read a customer, and the read will not appear in the CRM test notes, because the CRM test notes do not watch that tenant. Put the federation line on the list as "not connected" until a non-production source exists. Then connect that source, and only that source. If those three people do not have the list, they will do the reasonable thing and you will have a production incident described as a test. Give them the list before you give them the login. The login without the list is how the green run happens. When the list and the configuration disagree, the configuration is wrong. Change the endpoint, then update the list. Do not update the list to match a production host so the page looks tidy. Tidy is how a real subscriber receives a rehearsal. ## Questions ### Does a full Salesforce sandbox copy Marketing Cloud? No. A full sandbox copies the CRM org and does not give you a free copy of Marketing Cloud. Engagement, Account Engagement, and Marketing Cloud Next are different products, and none of them arrives as a clone the way Sales Cloud does. Name a non-production tenant, or write that you do not have one. A blank line is a gap, not a pass. Do not send, change consent, or run a journey against production because the CRM sandbox was free. ### Does the sandbox copy the production Data 360 tenant? No. Data Cloud was renamed Data 360 on 14 October 2025, and a CRM sandbox refresh does not hand you the production Data 360 tenant. The rename did not change that. Test against a named non-production connection, or record that Data 360 was not part of the test. A query of the production tenant, to see real data, is a production read, not a rehearsal. ### What should we write down after a refresh? The sandbox name, the date, what CRM data came across, which endpoints the connectors call, and what was not copied. Marketing Cloud and Data 360 each get a line. A blank line is a gap. Write the list again after every refresh, because a refresh can restore production URLs from metadata. An undated list expires. If a colleague cannot tell from the page whether the sandbox can touch production, the page is not finished. ### What if zero copy federation still points at production? That is a production read, even from a sandbox session. Salesforce describes connecting data with zero copy data federation. Point the connection at a non-production source, or disconnect it and write "not connected" on the list. A read is still production data leaving the boundary, and it is still load on the production source. Check the credential as well as the host. A test-looking URL with a production secret is a production call. ### Can we hit production "just to see" from the sandbox? No. A send, a write to the ERP, or a query of the production Data 360 tenant is a production change. If the system was not copied, say you did not test it, which is a valid result. Report the CRM test as a CRM test, and book the other test for the day a named non-production endpoint exists. Do not backfill an earlier pass once that endpoint arrives. The date on the list is the evidence. --- 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: Integration and architecture (https://synconai.com/salesforce-integration-services).