Dynamics 365 Software Deployment and Flow: The Good, the Bad and the Ugly


Of the developers I talk to, there are mixed feelings towards Microsoft Flow. There are a few reasons for this such as:

  • It is quite new and a little buggy in places
  • They do not get full control to bend it to their will (the reason they are a little less hostile towards Flow’s big brother, Logic Apps, where they can access the underlying code)
  • It provides Power Users with a lot of power but does not strongly enforce discipline/good development practices (this is improving with the new policy framework available for the Premium edition)
  • There is little guidance on managing Flow as part of software deployment

All of the above are true and developers have reason to be wary. However, the same concerns were raised when Dynamics CRM got Workflows and we learned to work with them (although there is still room for improvement in most implementations in regards to refactoring and taking advantage of Workflow properties such as scope.

In this blog I will go through what I have discovered for managing Flows as part of a Dynamics 365 implementation.

What Do I Mean By Software Deployment?

I have also seen this called the ‘Software Development Life Cycle (SDLC)’ but, basically, I am talking about the idea that you do not develop in a production environment but still need a simple way to move a developed solution to production with a minimum of fuss and human intervention.

A simple architecture involves a set of environments with the developed solution progressing through them to production.


Method 1 (The Good): Two Environments (Premium Option)

With a Premium Flow plan you get two Flow environments and the ability to export a Flow as a ZIP file for importing elsewhere. While more than two environments would be nice, it is a good start. Let us call our two environments DEV and PROD.

In this scenario, a new Flow is developed in DEV and then exported to a ZIP file via the Export option for the Flow.


When we do, we get a number of options for our ZIP package.


For the Flow itself, we have the option of having it update an existing Flow (as shown above) or we can make it create a new Flow for us in the target environment. While it looks like there are options for the Connections as well, the only option available to us is to select the Connection on import. We can also add in comments to guide the user during import.

So we can imagine we have our DEV environment with DEV Connections and PROD with PROD Connections. This is good as it means it is unlikely a user will connect, say, a Flow being developed to a production Connection accidentally.

To import, we go to My Flows and the Import button is at the top on the right hand side of the page. When we import the ZIP package we see the following.


As can be seen, any comments we added are available and it is now a case of clicking on the blue text for the Connections, linking them up to the Connections in the target environment and we are good to go. We can also create new Connections, if required.

For the Update option, the user can change this to create a new Flow, if they choose to.

Once the Connections have been selected, the Import button becomes blue and you are good to go.

Method 2 (The Bad): One Environment (Non-Premium Option)

Almost certainly by design, Microsoft have made it that if you are serious about managing Flow as part of a software deployment, you will need a Premium account.


So, given we cannot export a Flow out of our environment, the option of moving it is not available. Also, we only have the one environment to work in; no more DEV and PROD. Therefore everything has to sit in the one place.


Unfortunately, this is a disaster waiting to happen. We need to manually turn Flows on and off and the Connections to all environments are available for manual selection. It would be very easy to make a mistake in this setup and cause significant problems for production.

Method 3 (The Ugly): Using Flow Management

The last method I tried was my most ambitious. Flow now has a Connector to manage Flows. You can literally create, delete and modify a Flow with a Flow. This holds a lot of potential from a software deployment perspective because it means, for example, we could set up a Flow which deploys our developed Flow from DEV to PROD at the press of a button; deployment nirvana.

As Dynamics 365 CE (the new name for Dynamics CRM) already has a deployment packager (Solution files), I wondered if we could use Flow Management to push a Flow into a Solution and then piggy back on the CRM deployment process.

This proved to be frustrating and ultimately failed but I still hold hope for this technique. Here is what I discovered.

I Could Not Select a Flow from Flow Management

While we can add a text input to a Flow’s manual trigger, there is not yet a way to search and retrieve a Flow by its Display Name. You literally have to specify the Flow’s ID to retrieve it, which is essentially impossible for the user to know.


Without this ability to find a Flow based on a property other than its ID, it makes it hard to create a generic deployment tool for Flows and we literally have to create a deployment Flow for every Flow we plan to deploy, hardcoding the Flow ID into the deployment Flow definition.

I Could Not Put the Flow Definition in a Text Field

This appears to be a fundamental bug in flow at the time of writing. While the slug for the Flow’s definition is available and the documentation specifies it is text, if you try and put that definition in a text field as part of your deployment Flow you get an error:

” ‘The template language expression ‘body(‘Get_Flow_as_Admin’)[‘properties’][‘definition’]’ cannot be evaluated because property ‘definition’ doesn’t exist, available properties are ‘apiId, displayName, userType, triggerSchema, state, connectionReferences, createdTime, lastModifiedTime, environment, definitionSummary, creator, provisioningMethod’. Please see https://aka.ms/logicexpressions for usage details.’.”

Translating with the help of CRM development guru George Doubinski, the slug is looking for ‘definition’ but the only thing available which comes close is ‘definitionSummary’. After hacking around in the Flow interface I managed to convince it to ask for the definitionSummary and got back what looked like a definition for the Flow.

I Could Not Put the Flow Definition into the Content Field of a Web Resource

My grand plan was simple. Get the Flow into a Web Resource and then add this Web Resource into a CRM Solution file. Then it moves across, out of DEV, with the other CRM components. Perhaps I was selecting the wrong type of Web Resource but I struggled to get the Flow definition to appear in the Content field. In the end, for the sake of expediency, I pushed it into the Description field of the Web Resource instead.


I Could Not Use This Definition to ‘Rehydrate’ My Flow

While it was possible to read the text file into a Flow and set it as a definition of a new Flow via Flow Management, the Flow failed


In the end the issues were insurmountable and I have chalked it up to revisit in six months or so when Flow Management, and Flows in general, are a little more mature.


There is still some way to go for a practical solution for non-Premium accounts to manage Flows as part of a software deployment process but we have the start of a process for Premium accounts. By all means see if you can work around the issues I had in using Flow Management to move a Flow into a CRM Web Resource and let me know if you have more success.


One thought on “Dynamics 365 Software Deployment and Flow: The Good, the Bad and the Ugly

  1. I think many MS Online services suffer from these sorts of limitations, especially in their early iterations. There is often a lack of multiple instances, some global config that applies to the whole tenant or a security concern/lack of sufficiently granular privileges that means a new feature cannot be enabled for example for development/evaluation but remain disabled (for the moment) for live. I think this will always be the case.

    One way round this is to use multiple tenants – for example one for eval/dev/test and one for UAT/pre-prod/prod. In your enterprise flow example with two tenants you’d be able to have 4 environments.

    Unfortunately licensing for this scenario still appears to leave a great deal to be desired. Last time I looked whilst dev/test licensing existed for certain products in a different tenant (e.g. Office 365) it did not appear to be available for others in a different tenant (e.g. Dynamics 365CE/CRM) and one ends up having to pay production rates for some users a second time….


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s