When I first started working with Power Automate, I misunderstood a few key concepts. If I got the wrong idea, then I am willing to bet other people are working under the same misconceptions. That’s why I wrote this post on four things I misunderstood about Power Automate. Read on to learn more about these common misconceptions.
Resubmits
First up, let’s talk about resumbits. What does it mean to resubmit a cloud flow? When do you resubmit a cloud flow? Well, it’s common to build, test, encounter a failure, and make a correction. Then, rather than retriggering the cloud flow, you resubmit it instead.
My misconception was that I thought the resubmit allowed for changes in the data AND changes in the cloud flow. However, that is not the case. Resubmits always run with the exact same data, which is different from retriggering a cloud flow. Triggering the cloud flow again is the only way to incorporate new data.
I learned this when I was working on an automation triggered by filling out a SharePoint form. Occasionally, users would enter the wrong data in the form. They would then ask if I could correct it and resubmit. I tried to update the SharePoint list and resubmit. But, it doesn’t work that way. Resubmits account for changes in the cloud flow, not changes in the data.
You might want to consider this when building out processes. What will you do if data needs to be changed or modified?
Sharing Workflows
Next, I want to talk about sharing workflows. This one caught me off guard because in my mind, it runs counter to basic security protocols.
When you share a flow, it’s shared with your connections. If the person you shared it with runs the cloud flow, it runs as you, unless the other person changes the connection.
I realized this when a coworker shared a flow with me. I ran it a few times successfully before changing the connections from his connection to my connection. The flow failed because I didn’t have access to the SharePoint site the cloud flow interacted with. I also observed that the emails the cloud flow was sending were being sent from his account instead of my account.
All things considered, permission must be given to named individuals. Only people I have granted access to can run flows with my credentials. This is different from other applications I’ve worked with where you can simply enter a name or an email address and send from that account.
Connections & Connection References
When I first started working with Power Automate, I did not understand the relationship between connections and connection references.
In short, connections hold all the information (i.e. credentials) an action needs to connect to a Power Automate action. Connection references map to connections. Connection references don’t hold the information, just a mapping to the connection.
A flow can hold several connection references, and a connection reference can be used in several flows. Many connection references can use the same connection. This way, if the information required for an action needs to be changed, you can update the connection and all connection references will be updated.
Lastly, individual cloud flows use connections. But, solutions utilize connection references. As solutions move from one environment to another, the name of the connection reference will stay the same, but the details of the connection it maps to can change based on the environment. This is helpful because it makes moving between environments seamless.
If you are interested in learning more about why Power Automate is designed this way, check out this post.
Environmental Variables
And last but not least, let’s talk about environmental variables. I made some mistakes when I began working with environmental variables. I had good ideas but didn’t really understand the concept.
The solutions we build have to be pushed thru 4 different environments (DEV, QA, UAT, PRD). And, many of our early projects worked with spreadsheets stored in a shared drive. My concern was that the spreadsheet file paths would change, and I’d have to test and push thru 4 environments for something trivial. So, I used environmental variables to hold file paths. That way, if they changed, I could just update the EV rather than push thru all those environments. However, this isn’t how EVs should be used.
Instead, EVs are more about grabbing different values by the same name in each environment. For example, many of my automations use SharePoint actions. We have different SharePoint sites for PRD and pre-PRD. Storing the links as EVs is a better use case for EVs than file paths.
What Did We Learn
- Resubmits run with the exact same data and only factor in changes to the cloud flow.
- When sharing cloud flows, the flow will run with the creator’s credentials unless the connection is changed to another user.
- Connections hold the information required to run an action. Connection references map to connections but don’t actually hold data or credentials.
- Environmental variables should hold values specific to an environment.