F&O 💙 Power Platform – Where’s my Dataverse DEV?

In a previous post, I gave an introduction to dual-write, one part of the Power Platform integration with F&O. Dual-write provides an OOB infrastructure for setting up integration between Dynamics 365 Finance and Operations (F&O) and Dataverse, Dynamics 365 CE apps. In this post, I will let you in on general findings related to this subject and environments in particular.

Imagine you are about to enter a new project and it’s not your usual safe space that CRM often means, it’s also ERP (Dynamics F&O) involved. On the ERP side they have a test environment and another environment which is about to be the production environment. Then they have lots of different development environments, one per X++ developer. Now you start to talk about setting up dual-write and link F&O to Dataverse. Production to Production, Test to Test… But wait a minute…

Where’s my Dataverse DEV?!

Note! Managing F&O environments is about to move from LCS to PPAC (Power Platform Admin Center), i.e. the environment provisioning part will change. This post is written based on how the setup has been done “the old way” with F&O still in LCS.

Environment Strategy

In the Power Platform chapters of Microsoft Learn you can read about establishing an environment strategy from a Power Platform perspective. When your organization start to create their own apps you need a strategy for how environments are provisioned, governed, what apps and flows should live where etc.

You can read about different types of environments. For instance Default and Developer environment, that’s not for our ERP + CRM projects. Dedicated environments (at least Dev, Test, Prod for our specific project) is what we traditionally setup for our CRM projects. Then we might want to utilize more parts of Power Platform later on and we can evolve our strategy to include more than the environments dedicated to our specific implementation.

In the Dynamics 365 Guidance documentation you can read about environment strategies from a Dynamics 365 perspective. In the Dynamics 365 F&O chapters you can read about environment planning from an ERP perspective and find a sample overview of environments.

I am not saying you should be the one managing it all. Most likely there will be an experienced F&O partner involved and a partner experienced in Power Platform, Dataverse and the CE apps (CRM). However, no matter where you fit in, It’s good to have an overall understanding. Then it’s easier to talk to all parties involved.

Example of an Environment Strategy

Most likely you have already established a strategy on the F&O side and perhaps also on the Dataverse side. It depends of course, if you are live with one of those sides yet. How now to put these two sides together to a combined strategy?

Thing to consider: How many set of environments do we need? Do we need dual-write up and running for them all? Development/configuration cycles for F&O and Dataverse? Deployment processes? Updates to the first-party apps (F&O, Sales, dual-write related solutions). How to handle db refresh prod to UAT?

Note! A Power Platform person might talk about Power Platform environments or Dataverse environments. It’s basically the same, just that it can contain a Dataverse database (with or without Dynamics 365 apps) or not.

Here is an example, taken from a real-world scenario. I have been involved in several projects with dual-write and the set-up has been somewhat similar. Sometimes POC and PRE UAT sets were excluded.

All F&O environments except for UAT and PROD have been cloud-hosted by the way. The arrow means they are linked together with dual-write enabled.

Environments explained

Let’s go though the different environments and talk more about their purpose. Note that in the future we will look at F&O and Dataverse as one and the same probably, this is how we have set it up when F&O has lived in LCS.

POC for POC (Proof of Concept) purposes, to test dual-write in a safe space and explore how it might work together with your business processes. One set of F&O 💙 Dataverse is good for a POC and later on the POC environment can be deleted.

DEV1, DEV2 for F&O development only. F&O custom development will be deployed to F&O DEV3 (e.g. custom fields to be included in the dual-write mapping later).

DEV 3 to be seen as the DEV for Dataverse configuration/development and table maps modifications. F&O DEV 3 has one purpose only, to be a matching F&O environment for the Dataverse DEV environment. Here we have the source for table maps as well as the source for Dataverse/Dynamics 365 CE apps customizations and development.

PRE UAT is an extra pair of environments which might be handy if you want to be able to test dual-write and work with a longer implementation but do not want the environment to get overwritten (db refresh on F&O side only because you are not live with CE apps/CRM yet). Then UAT can be your environment where you test new F&O versions with the latest data, PRE UAT could live without DB refresh. We simply found it time consuming to relink and resync each time a db refresh was done.

UAT “User Acceptance Test” The environment that get refreshed from production quite often in order to be able to test new F&O versions with the latest data from production. Dual-write sync up and running and relink is done when refreshed.

PROD The production environment. We all know the purpose of this pair of environments.

Where is my Dataverse DEV?!

Back to where’s my Dataverse DEV?! I need a Dataverse DEV environment. I need it as the source for table maps. I need it as source for Dataverse configuration and development. But which corresponding F&O environment do we have?

F&O Production linked to Dataverse Production, F&O UAT linked to Dataverse UAT. Quite obvious. But then, as already mentioned, it has not been so obvious what F&O environment to link to a Dataverse DEV environment to. What we have done is to setup a new F&O DEV, cloud-hosted, with the purpose to be the F&O linked to Dataverse DEV.

Why all those sets of environments?

On the F&O side there is (or will be) a production environment. Most likely also a UAT environment. There might be one or several (cloud-hosted I assume) development environments. Why? Well, you might have custom development and you probably want to test new OOB F&O versions in a test environment before updating in production.

On the Dataverse side there is (or will be) a production environment and most likely also a test environment and a development environment. There might be several development environments depending on the amount of Dataverse customization and development and there might be further environments for different test purposes as well. Why? Well, same as with F&O. You want to test things in a test environment first and we need a dev environment to have our “source” and to make new configurations while someone else can test in a test environment without interference from new configurations/development.

Golden configuration

My friend Nurlin told me about something that is common to have in F&O projects, a golden configuration environment. I have not included that in my example in this post, but wanted to bring it up. As I understand, it is usually the case that you have a golden configuration before you are live on the F&O side.

Below is a picture from the FastTrack Team where the golden config is present. (5:48 into this recording; Best Practices: Dual Write Cutover). Read more about golden config here: Golden configuration promotion.

What’s next?

This was the first post in a series of posts. In the upcoming posts I will bring up subjects like what to think about when linking environments together, how to handle db refresh before and after you are live in a production environment on both F&O and CE apps/CRM side and how to handle ALM related to dual-write. Stay tuned!

It would be interesting to hear about your experience for environment strategies when dual-write is involved. Let me know what has worked well for you!

Photo by Robert Ruggiero on Unsplash