Some Dynamics 365 administrators have found that installing Dynamics 365 for Marketing in their dev environment prevents them from moving their configuration changes to production.

Trigger warning–licensing talk ahead (but trust me, it will be worth it)

To understand why this is, you first have to understand how the marketing solution is licensed. Unlike almost every other Microsoft solution, D365 for marketing is licensed by the environment, not by user.

D365 for marketing is priced based on the number of contacts included in marketing activities over a 12 month period in an environment. This makes the pricing scale based on the amount of marketing that you do (and is very similar to other marketing automation providers), and each environment needs to be licensed for Marketing.

The problem comes when trying to move solutions if the Marketing app is not provisioned in the target environment. Dynamics 365 for Marketing adds dependencies to the appointment and user entities, so you will not be able to move these entities in an unmanaged solution from an environment with D365 for Marketing to an environment without D365 for Marketing.

See the official documentation for how Marketing apps are added.

But wait–we have marketing included in our license

You may have received a free marketing app with your Dynamics 365 Customer Engagement license–congratulations. Just understand that this doesn’t mean you have a license for all instances. When you provision that instance, if you choose to put it in your dev environment, you will also need to license it for production.

See the FAQ about the “free instance.”

Recommendation

If  you receive the “free” marketing app but you aren’t 100% sure if you are going to use D365 for Marketing in production, don’t provision the free app against your primary development or UAT environments–you can now have as many CDS/D365 environments as you want, so if you just want to stick your toe in the marketing pool before you are fully committed to it, spin up a new environment and install your free app there. That will avoid creating unwanted dependencies.

By setting up a separate dev sandbox for marketing and not installing marketing in your core dev environments, you will avoid adding dependencies for Marketing to your core configuration.

Finally, if you find yourself with configuration dependencies because Marketing is installed in dev and not in downstream environments, you will need to manually remove the lookup fields and navigation links from the entities with dependencies before you can move your solutions. Alternatively, moving your configuration changes in a managed solution may work (but then you need to be prepared for the ramifications of managed solutions).

Cover photo by marc liu