Client has acquired another brand and is setting up the acquired brand as a child BU in Marketing Cloud. When creating the new child BU we reviewed the current implementation and the Unsubscribe Settings are set to:

Subscribers will be unsubscribed from all business units in the Enterprise

However, it's possible that a subscriber is a customer of both brands so we don't want an unsubscribe from the "parent" to automatically unsubscribe users on the "child" account. What we want is to change the setting to:

Subscribers will be unsubscribed from this business unit only

In reviewing this Stack Exchange post, it seems like this is not possible, but I can't imagine other organizations haven't had the same issue before...?

For our other multi-tenant clients we have a singular Parent BU and each brand is a Child to it; we're OK there because no email deploys from the Parent and we knew this from day one.

  • 1
    Parent status will always be leading. Don’t you have a Data Extension based consent management? In contemporary implementations I will not use list based subscriptions. Instead a master consumer data extension where one or more fields define what the given consumer is subscribed to. This will of course require custom preference centre. Commented Sep 11, 2019 at 19:53
  • Yes, we do... but if someone replies to the email and says "Unsubscribe" then the users will be excluded from both brands. Same goes for SPAM complaints. We'd like to avoid this. Commented Sep 11, 2019 at 21:14

2 Answers 2


This is what I would do in your case. Not knowing if your system of record (SOR) for consent data is within SFMC itself (e.g. in a Consent data extension) or outside, this solution will differ slightly.

Firstly, a job needs to be set up in Automation Studio (in parent BU) to query your Complaint and Bounce data views. Once a day you (or more frequent, depending on your needs) you would query these two data views, and filter records on eventdate > your last automation run and OYBAccount = MID where the event has taken place, and is the BU from which you want to unsubscribe.

Once you have found the Subscriber Keys which have either bounced or complained, you should update your consent data extension (or call the unsubscribe API of your external SOR for consent). This will ensure you only unsubscribe from the newsletters for that given brand. Additionally you should update the All Subscribers status to Active, since otherwise your subscribers will not be able to opt back in using your regular preference center, as their All Subscribers status will block any future sends. This approach will also ensure that there is only a single source of truth for consent, and it should not be the All Subscribers in your case.

You can reactivate Subscribers with a Script Activity in Automation Studio, which is described in few threads already: How to resubscribe a user in Marketing cloud using SSJS?

Activate a Subscriber from Server Side Javascript

SFMC - SSJS Bulk update to All Subscribers list

  • Just in case someone stumbles upon this answer, according to SFMC support, OYBAccountID is only populated where the Send is originated from a child BU. If the sends originate from the Enterprise Account, OYBAccountID is set to NULL. So, if you want to get this field on the Parent BU, you can use something like "ISNULL(OYBAccountID,AccountID) as OYBAccountID" because OYBAccountID is equal to AccountID on parent business units.. Commented Sep 1, 2020 at 8:38

From past experience, support will not be able to change this setting. We raised it through Account Executives who raised it through their internal contacts, but we were told it's not possible. Never hurts to try on your side though.

We explored the path of having the current Parent 'transformed' into a child business unit and replaced with a new clean Parent, but were told this was also not possible. Apparently once you're a Parent you can never be switched. The only option was to largely manually migrate items from the parent into the new child, which is a painful process.

One option (not ideal but I'll through it out there): In the child BU, use a custom preference center to update custom fields (in SFMC or integrated CRM) relating to opt-in status. Effectively ignore the All Subscribers status. Set all sends to transactional to bypass existing opt-outs. Ensure that RMM and other feedback-loop type opt-outs are tracked and respected with your custom fields opt-in through automations. Not perfect by any means but may help!

You must log in to answer this question.

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