Filtered Data extensions or Data extensions fed with SQL queries to duplicate Synchronized DEs from CRM to share with child BUs?

Question

We have a SFMC org connected to SF CRM with one parent BU and one child BU. We need the Synchronized DEs from CRM to be available in the Child BU.

As we can not move the Sync DEs in a Shared folder, we have to create brand new DEs containing the Sync DEs data in the Shared folder.

As there are many fields on the Sync DEs with API names of the fields, it is a very tedious work to create a DE from scratch to copy the Sync DE...

I wanted to create Filtered DEs from the Sync DEs in order to get the whole data without having to create DEs from scratch with many fields. And then use an automation to refresh it every 15 minutes.

Is there any warnings/risks/drawbacks to use Filtered for that purpose that VS creating DEs from scratch and fill them with SQL queries (refreshed by an automation) ?

Which solution is the best or more convenient ?

Thank you

Regards

Answer 1

There is a few ways to achieve your scenario,

1. Configure Multi-Org and connect the same CRM to the child BU independent, this will give you access to the Synchronised DE’s at the child level directly. The main purpose of Multi-Org is to connect multiple CRM’s to the one SFMC account, you also have the option to connect 1 CRM to multiple business units which in your case is what you will need.
2. Replicate the Synchronised Data Extensions in the Shared Data Extension folders as standard Data Extensions as oppose to filters so you can have the ability to filter from the standard Data Extensions to obtain a snapshot of data when required, you will also have the ability to query the data.

The reason I would not recommend your approach of creating filters is because you can’t filter off a filter, you can only run queries on them, but you can filter off a standard DE and run queries. With Standard Data Extensions in conjunction with Queries you also have the flexibility to control how you treat the data being synced as well as only syncing relevant fields for the child business unit.

There might be other benefits but I would go with either option above as they will both do the job.

There are no additional costs associated with Option 1 but there are platform considerations and permanent changes that will apply if you take this route, please read carefully through the Multi-Org documentation before choosing Option 1 if that is your preference.