How to Build a Manageable Power Automate Solution

When we first began working with Power Automate solutions, we set up all solutions as unmanaged. This is not recommended, but we did it because learning new technology is hard. What we lacked was information on how to configure triggers and actions so that we could change things like SharePoint site links as solutions moved between environments. We’ve since learned how to work around this, but that’s the problem. It feels like a workaround. I want to show our solutions and also ask for some help. Both of these methods feel not quite right, and I can’t help but think there’s a better way. So, please give this a read, and tell me if there’s something I’m missing.

To begin, I want to provide background information on managed and unmanaged solutions.

Managed vs Unmanaged Solutions

All solutions in the Microsoft Power Platform start as unmanaged solutions. Think of managed and unmanaged as a general setting or type for the solution.

If you want full details, click on this link for the Microsoft Learn page on managed versus unmanaged. If you don’t have time for that, understand that when unmanaged, you can add, edit, update, remove or delete solution components. When managed, the solution cannot be edited. Generally speaking, solutions should be unmanaged when working in development environments. Once past development, convert them to managed. Although, once you deploy as managed you cannot change back to unmanaged.

The Problem

So, when we first began deploying solutions across environments, we deployed unmanaged all the way from QA to PRD because we did not know how to set up triggers to update things like SharePoint sites. With the unmanaged solution, we would push the solution to the next environment and then manually update the site address based on the environment.

And that wasn’t terrible until it was…until we had a solution with 12 cloud flows that all used SharePoint triggers and actions. Our automation team was doing far too much manual work.

So, we came up with 2 fixes for this problem. One of them feels clunky and adds a whole bunch of actions that we didn’t have before. The other just seems not right.

Fix Number 1 – If Statements & Variables

The first fix involves writing an IF statement into the trigger that says, if you are in PRD, go to this site. If you are not in PRD, go to a different site. This works for the trigger, however….

The cloud flows have many other SharePoint actions past the trigger. So that we don’t have to write a ton of IF statements, we create variables and then reference the variables as shown here.

However, we need to do this for more than just the site links. There are other references to library paths and ids. It turns out, we needed a lot of variables, which is why this particular usage seems clunky.

Fix Number 2 – Environmental Variables & Conditions

The other method I tested out was putting the SharePoint site URLs into environmental variables and using a condition as shown below. But this seemed like a bad idea because…

• I still had to write IF statements in the triggers. That didn’t go away.
• This means adding the PRD and non-prd URLs to all environments, which seems out of character with the concept of environmental variables. An EV should be specific to that environment.
• I’d wind up with a whole lot of environmental variables holding SharePoint URLs.
• This doubles the number of SharePoint actions.

Conclusions

So, fix number 1 is what we are doing now, but it just doesn’t feel right. I’m not convinced what we are doing is the right way to go. So, if you made it this far and have an opinion, I would love to hear it.

Other Sweet Power Automate Content

• How to Trigger Power Automate Flows From Teams
• Power Automate Corrupts Excel File Contents
• How to Update Excel with Power Automate