We are about to create an SFMC test BU for a Business unit with our SFMC Account. I am wondering if it is best practice to make this test BU a child of the BU that is the production one. Basically we have an Account parent BU and below that is a child BU. This child BU uses the MCC to synch with our SF CRM prod org. Should we have the test BU that will use MCC to synch the SF CRM SIT org the child of the one the synchs with the SF CRM prod org?

a) Is a child of
Account Parent
      >Brand A Prod_BU
         >Brand A Test BU

b) Is Not a child of 
 Account Parent
      >Brand A Prod_BU
      >Brand A Test BU

1 Answer 1


I have a suspicion this might be closed as opinion-based.

...is it even "best practice" to use multiple BUs for sandboxing? Who is to say. In order to keep opinions out and stick to reproducible things, let's say "there are considerations you should make". The potential BU hierarchy is not really among them:

  • There is no real data isolation inside SFMC. With sandbox and prod connected, you in effect mix prod and test data to some degree (e.g. all subscribers list), among other risks this has effects on your billable contact count;

  • deployment from test to prod has "manual steps" (when graciously taking into account that things like the API, package manager etc exist and you have put a lot of effort into covering most things automatically), which makes deployment an additional error source in itself rather than a "mechanical" step to enforces synchronicity. In other words: If you change something in sandbox, chances are you have to retest it all over again in prod. Sidenote: this starts with the connector package itself which is not deployable but is two separate installs.

  • add to that: The existence of an Enterprise Level BU stays in place in the backend as a remnant of the BU hierarchy. This means that code in Sandbox and Live cannot be equal - e.g. a script or an SQL query in any other but the former parent BU still has to use "ENT." prefix to access, say, All Subscribers, or other Enterprise level entities, like the _open dataview. The same script will break once moved to prod = Parent BU ,until you remove "ENT." - in such scenarios, deployment could be the only error source in a script that worked flawlessly in Sandbox.

  • Any Contact ID is a Contact ID, no matter what system it comes from. Plus, Sandbox Refreshes will recreate all Ids, including User, Lead, Contact which will create billable duplicates that you should take care of.

  • Sandbox refreshes can lead to other problems such as: https://help.salesforce.com/s/articleView?id=000322378&type=1

  • marketing cloud releases are rolled out by Salesforce regardless of what you call your BU >> "sandbox" and "prod" BUs receive global changes at the same time.

  • Do not use your sandbox for load testing or similar as detrimental effects can also impact prod.

  • your sandbox is not "harmless" as it is not really a sandbox. You can e.g. totally send data to the wrong people at scale, in seconds. Every additional measure you put in to prevent this has to be built in such a way that it only occurs in the sandbox and exists, but is ignored in prod.

If this sounds like a best practice to you, or if you have other arguments that outweigh this, is probably the more opinion-based part :)

  • +1 In SFMC everything should be considered "production" and "environments" are simply copies to manage. Jan 17, 2022 at 11:24
  • that is a much more concise way to put it :D cheers! Jan 17, 2022 at 11:40
  • Thanks for that Jonas & thanks to you Adam. When you line up all of those facts, it certainly feels like a test BU is simply more trouble than it is worth! Regardless, I will have to follow through with its creation as it has been a decision made by the broader team. I will go with the option b) and just have the parent and two same level child BUs. Thanks fellas!
    – Weenus23
    Jan 17, 2022 at 21:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .