Build Deployable Power Automate Flows for Dynamics Customer Voice with Environment Variables

Dynamics Customer Voice is the survey tool that stores all its data in Dataverse. Dataverse have quite the process to maintain a healthy ALM and deployment process, but if you plan to include Customer Voice in your solution it can complicate things. This is how I solved this challenge, with help and inspiration from my colleague Carl Gustavsson.

ALM and healthy deployment

Being a former superuser (back in Dynamics CRM 2011) who occasionally dabbled and made changes in production, I early became aware of the importance of a healthy ALM and deployment process. Having those is all about wanting to make sure that your changes you want to make are done in a controlled environment, tested in a second one and then transferred into your LIVE environment, so that it doesn’t effect the day to day things that needs to be done. I know it sounds unreasonable, but I’m not flawless so I really want to make sure that my mistakes are effecting as few as possible before I have the chance to correct them. Sometimes, maintaining a healthy ALM is a bit tricky though…

What’s your problem, Customer Voice?

For as long as I’ve been around in this business we’ve used solutions to transfer Dataverse (previously CDS) between DEV, TEST and PROD environments. I’ve also used Shuffle Runner (you can read about how I use this tool here) to transfer necessary data configuration, meaning data that is stored in Dataverse and not how it’s configured. That type of data usually includes a unique identifier column so you can write automation like workflows and flows with filters and actions depending on that data.

When Customer Voice became part of the Dynamics and Dataverse Universe my spontaneous feeling was to treat it like I’ve treated data configuration previously, with a unique identifier that can be the same on all environments and build my logic depending on that. Unfortunately both the Power Automate actions for Customer Voice and the datamodel of Customer Voice doesn’t work like that.

Problem 1: The Customer Voice Actions to Send a Survey

To start with, the action to “Send a Survey” for Power Automate from Dynamics Customer Voice need you to specify the specific Project, the Survey and the E-mail Template to use.

But I have three projects that look the same (one each in DEV, TEST and PROD). These lists are also dependent on each other, so if I were to use Environment Variables or dynamic data to store the GUID for Project for example and then populate that, my choices of survey and e-mail template would be blank and I would have to handle them in the same clunky way.

Problem 2: The Forms action to get response details

Here lies the real issue. To get the actual response from a survey in a manageable way you have to use the Forms Connector and the action “Get response details”. The problem with this is if you populate Form Id with a GUID or dynamic data, you don’t get your response details as dynamic data – which is kind of the point.

So I actually have to pick out what Form Id (that is the survey) that I want to get the response from.

Summary of problem for you who don’t want to read the whole thing

Okay so my main problems is pretty much that to be able to utilize the power automate actions related to Customer Voice in the best way I need to hardcode the survey in the actions, and the survey is different in each of my environment. How do I deploy and maintain this?

Step 1. Copy and Update your Customer Voice Project

When you create a project in Customer Voice you first get to decide what environment this should be saved in, in my customer projects I obviously choose my DEV environment (pic below is my own tenant and doesn’t have a dev, test and prod).

After I’ve created my project in my DEV I make sure I only use the copy and update functions on the projects to TEST and PROD, this is to make sure I have as little administration as possible.

Step 2. Create a child flow for Environment Variables

Create a child flow that you can run to get your existing environment variable value. I’ve chosen to use a child flow instead of the dynamic data variable to avoid the some of the current limitations of environment variables. Here is a good read about it at Tip of the Day.

Step 3. Create an Environment Variable for your Environment type

Create an environment variable for my environment type, meaning DEV, TEST or PROD (or other?). I did not put in a default value because I do not want it to be deployed (obviously, duh Sara).

Also obvious but yeah, create a local value for this variable in each of the environment that you can use in step 4.

Step 4. SWITCH my shit up in Power Automate

Next thing I do is to trigger my flow with appropriate trigger. Run the child flow to get current environment the flow is being run in, then use the SWITCH option to send a survey or get the responses based on the value I get back from my child flow.

Send Survey

Get Response Details

When I get my responses I also choose the save that data into a variable, because I want to use it in later actions in my flow.

Then I can just Parse JSON on that Variable and I got my dynamic data as responses no matter what environment I run the flow and the data is in.

Tadaaa, all set. Now I have deployable flows!

Summary

Obviously this is not bullet proofed. If we were to add an environment for training or other reason there would be need to create yet another copy of the project and a new switch case in the flow. But for now it’s the healthies ALM I got, that makes the flows readable and maintainable.

Did you enjoy this post? Please let me know!

Original Post https://saralagerquist.com/2022/03/09/build-deployable-power-automate-flows-for-dynamics-customer-voice-with-environment-variables/