Deploying changes across Marketing Cloud Engagement business units is tricky for a few reasons, one of which is assets (such as emails) requiring unique keys across all business units. Gearset helps manage this during deployments, but it's recommended to follow some best practices.
As the maturity of DevOps in Marketing Cloud Engagement is in its infancy, it's likely that you would have deployed changes from development business units to testing and production business units by manually creating new metadata and copy-pasting the contents. Each time you create a new piece of metadata Marketing Cloud Engagement assigns a unique identifier for it, usually referred to as the Customer Key.
Because these are unique and randomly assigned there's no way to link that a Journey created in Dev org is related to a Journey in Prog org - so here's our suggested best practice to make the most out of Gearset's support for deployments in Marketing Cloud Engagement.
Brand new metadata
If you're working on something new, simply create the resources in your development business unit and use Gearset to deploy into subsequent business units.
Leave the Customer Key as a GUID (for example the 36 character value a716280e-11e5-43da-ae68-5b96625146b6 in the example below), and we'll manage keeping the customer key unique and synchronised across your business units. We'll also update references to those assets where needed (e.g. when you're deploying a new Journey which uses a new Email).
β
Working with existing metadata
When you run a comparison for the first time you'll likely be faced with something like this - two emails that are the "same", but in Gearset they are being identified as being New and Deleted.
In order for Gearset to be able to match metadata items across your business units, we suggest back-syncing your changes from Production business units into Development business units when working with them in Gearset for the first time.
Just deploy the items you want to work on from Production to Development, iterate on them, and when you go to deploy from Development to Production (and anywhere in between) you'll be shown the matching items in Gearset.
β
After deploying from Production to Development, the comparison looks like this:
β
Now there's a Different version of My First Email (the (1) is appended to the end of the name as we already had an email named My First Email in Development), and this is the item we'll make our changes to.
We can also delete the New item called My First Email from Development and then fix the name of the other item by removing the (1), but it's not strictly required.
Manually linking items together
For metadata types that you can define the Customer Key for you can also manually link items together by changing the Customer Key.
β
Note: Journey is a notable major type that has fixed keys so you cannot update them after they've been created, so you'll have to do the back-sync deployment to synchronize keys across your business units.
For assets (like Email) you'll need to modify the Customer Key by adding a suffix to it. You can find the per-business-unit suffix by navigating to the Marketing Cloud orgs page and selecting your connection - the suffixes will appear in a table in the right-hand panel:
In the case of Assets the Customer Key is restricted to 36 characters, so our Assets' keys would look like the following:
Business unit | Original ID | Updated ID |
|
|
|
|
|
|
We've done two things here:
We've chosen a single key to share across the business units - in this case the key from
Production,d0dfe925-3c32-44fd-bbe3-a3dbc9ce7b71.Updated each business unit's instance of the asset with the shared key with the business unit specific suffix.
For other supported types, simply ensure the Customer Key is the same in all your business units and we'll match them up.




