We need Real-time Journeys to support the Parent/Child relationship between Business Units. Meaning, a user in a Parent Business Unit can create assets that allow Contacts in both the Parent BU and its Children BUs. A user in a Child Business Unit can only create assets that allow Contacts in the Child BU.

Today, even when we have the real-time feature switch for BU support and modernized business unit support features enabled - the system does not allow this. This means we have to duplicate every single asset we want to use for every single child BU which is not feasible.

If my parent BU is USA and every city is a child BU - that would mean 19,495 copies of the same asset is needed to support a common marketing campaign. Consider the use case: send a welcome email to any new resident in the USA. This would require 19,495 copies of the same trigger, 19495 copies of the same email, and 19495 copies of the same journey to support every city.

Here are our official use cases in more detail:

BUSINESS UNIT CONFIGURATION

1. The parent business unit is USA. We could also consider this the “corporate” level.
2. Each city is setup as a child business unit. We could also consider this the “franchise” level. For Example: Chicago, New York, Fort Wayne, Birmingham, etc.

USE CASE 1 - PARENT LEVEL

·        The Parent Business Unit should have access to see all assets for all of its Child Business Units

·        The Parent Business Unit should have access to create and share any Marketing asset with a single or multiple Child Business Units – it should not have to duplicate the same asset for each individual Child Business Unit

·        The Parent Business Unit should have access to all dashboards and reports with data for itself and all Child Business Units

·        The Parent Business Unit should have access to create a Journey that allows Contacts or Leads to enter for itself and any child business unit – it should not have to duplicate the same Journey for each individual Child Business Unit. If the Parent Business Unit wants to create a Journey for only its contacts, it can apply a condition.

·        The Parent Business Unit should have access to create a Trigger that allows Contacts or Leads to enter for itself and any child business unit – it should not have to duplicate the same Trigger for each individual Child Business Unit. If the Parent Business Unit wants to create a Trigger for only its contacts, it can apply a condition.

USE CASE 2 - CHILD LEVEL

·        The Child Business Unit should only have access to see assets for itself and those shared with it by other Business Units

·        The Child Business Unit should have access to create and share any Marketing asset with a single or multiple Child Business Units – it should not have to duplicate the same asset for each individual Child Business Unit

·        The Child Business Unit should have access to all dashboards and reports with data for itself only, no other Business Unit

·        The Child Business Unit should only have access to create a Journey that allows its Contacts or Leads to enter – it should not allow Contacts or Leads from any other Business Unit. 

·        The Child Business Unit should only have access to create a Trigger for its own Contacts or – it should not have access to create a Trigger that allows Contacts or Leads from another Business Unit.

·        The Child Business Unit should have access to create and share any Marketing asset with a single or multiple Child Business Units

Organizational Impact

·        Let's say an organization has 102 BUs, having to individually manage a marketing asset 102 times is a huge burden that they do not have support staff for. Any condition change that they want to make, they are unable to apply that to all areas

·        Most BUs do not have their own IT support staff to manage marketing assets, it is managed at the USA level so asking them to replicate a change 102 times is not sustainable

·        Many competitive offerings can share an asset across multiple business units and security layers

·        This need is not unique to our client nd will be a major issue for any federated or affiliated organization with similar needs