Wouldn’t it be nice if we can Test our Flows without executing some of the actions like Sending Emails, creating items in SharePoint or Dataverse?
Guess what we can! And its very easy to do. Check this out!
If your like me, you test your Flows over and over again. This results in sending unwanted emails, creating items in SharePoint or Dataverse, Creating files on OneDrive or SharePoint. Every time you test your Flow, these actions inside our Flow get executed and cause unwanted behavior when Testing.
Wouldn’t it be nice if we can Test our Flows without executing these actions? Guess what we can! And its very easy to do. Check this out!
Scenario
For example, I have a Flow that Create a new row in Dataverse, and then send an email to the person who created the new row. That is fine, but what happens when we have other actions in our Flow that we want to test to make sure they are correct. I may want to test the Flow multiple times if I am doing some data manipulation, but this will result in Creating multiple unwanted rows (records) in Dataverse, as well as send emails every time.
We can clean up the testing process easily.
How?
We can utilize a feature called Static Result.
First click the 3 dots on the action, and select Static Results.
Next we can configure the static results. For easy example click the radio button to enable, select your Status, and the Status Code.
Click Done.
Now the action will have a yellow beaker, indicating that the action is using Static results.
Things to note: – Static Result are in ‘Preview’ so it could change at any time – Not all actions will be able to use them – If the option is greyed out, and you’re certain the action is able to use it, save the Flow and re open
This is only the beginning, as you can create a custom failed response, or create any result you want. This can help troubleshooting and testing certain scenarios.
REMEMBER!! To turn off static results when you want to execute the actions like normal.
Examples
Some examples on when to use static results:
Flow runs without sending emails
Flow runs without Approvals needed
Flow runs that need to test errors on certain actions
I have used this feature for awhile now, and noticed not many know about it. It’s so useful in many testing scenarios. Just remember to disable the static results once your done testing!
If you have any questions or want to add anything please leave a comment and like this post! Thank you!
Uploading data from Power Apps can be scary on a security standpoint, since the user will need access to the Data Source. Lets use Child Flows to get around this, and use any connection we want.
You may have run into an issue when creating Power Apps that needs to submit data to SharePoint, Dataverse, etc. But did not want to give everyone in the app access to these. The problem is, Power Apps uses the connections of the user using the app, meaning if the app writes to a SharePoint List, the user will need Read/Write access. The same goes for Power Automate if we try to send the data to Power Automate from Power Apps, it still uses the users connection who triggered the Flow. How can we get around this? Read below!
If you block the HTTP Request connector via data loss prevention (DLP), child flows are also blocked because child flows are implemented using the HTTP connector. Work is underway to separate DLP enforcement for child flows so that they are treated like other cloud flows.
You must create the parent flow and all child flows directly in the same solution. If you import a flow into a solution, you will get unexpected results. Call Child Flows – Power Automate | Microsoft Docs
Prerequisites
The Flows must be created inside the same Solution, so a Dataverse database must be configured on the Power Platform Environment
The Scenario
In this scenario, I will be showing how a user can use Power Apps to create items in a SharePoint List without being a member of the Site. This will allow us to use a specific Service Account to create the data in SharePoint without giving the user in the app any permission at all!
First we will build the Child Flow, then Parent Flow, and lastly customize the Power App
Child Flow
Inside your Solution create a new Cloud Flow.
For our trigger we use a Manual Button, and add the data we are expecting from Power Apps to put inside our SharePoint List (In my example I am only bringing in one field for Title)
Next, I add a Create Item action for my SharePoint List, and add the Parameters from the trigger inside the action.
Lastly, I add a ‘Respond to PowerApp or flow’ action, I create an Output called Success, and some details about what was created.
Child Flow
Make sure to use the Connection you want users of the App to use for the SharePoint Create item action.
Save and go back to the Flow dashboard screen (where you see the Details and run history screen).
There will be a Card on the right side called ‘Run only users’ click Edit
Run only users
Under Connections Used, switch ‘Provided by run-only user’ to the connection you want to be used by users of the App (They wont have access to this Connection outside this Flow)
Run only user
Click Save,
Now onto the Parent Flow
Parent Flow
Go back to the Solution and Create another Cloud Flow.
For our trigger we use the PowerApps button trigger.
As best practice, create Variables for your data that is coming from Power Apps. Don’t forget to name them, as this will be the parameter name in Power Apps, Use the ‘Ask in PowerApps‘ dynamic content for your variable values.
Next we use a action called ‘Run a Child Flow’ (If you do not see this action, your Flow was not created inside a Solution) Add the parameters (these were the input parameters from the last Flow that we just created).
Lastly, add ‘Respond to a PowerApp or flow’ action. For this demo I am adding the parameter ‘Success’ this is from the child Flow.
Click Save.
Power App
Now onto the Power App, I am going to create a simple Power App with 1 TextInput for Title, and a Button to Pass the data to Power Automate. Here are my controls for reference:
TextInput_Title Button_SendToFlow
For the Button: 1. Add the Flow to the button by clicking on the Button, 2. Clicking Action tab on top of page, 3. Clicking Power Automate 4. Select the Flow
Next add the parameters for the Flow, in my case I am adding the TextInput_Title.Text
Now, I want to add a Notification that the Item has been added, which will confirm my Flow has Run correctly. Ill be using the ‘Success’ Output parameter from the Flow for this.
To add this, I put my Flow run inside a Variable inside Power Apps. Ill call my variable Results, and IO add this to the OnSelect property of the Button where my Flow is:
Now I use the ‘Notify’ function to notify the user of the item being created, I add this after the semicolon. So my function looks like this in the end:
Did you know that Power Automate has a Date Time action that can easily convert, and format time zones in one action?
Why is this important? Power Automate natively uses UTC as its time zone, as well as most SharePoint sites. Using an action can be easier than using expressions.
Summary
Did you know that Power Automate has a Date Time action that can easily convert, and format time zones in one action? Why is this important? Power Automate natively uses UTC as its time zone, as well as most SharePoint sites. Using an action can be easier than using expressions.
The Flow
In this example, we will want to get the current time (this will be in UTC since we will be using Power Automate) and converting the time to local time with a specific format.
First we want to get the current time, we can use the expression utcNow() but I will be showing how to use the Date Time actions instead.
The actions are under Date Time:
Add a Current time action, this action is the same as using utcNow() expression
Next add Convert time zone action, this action is very useful as it has pre loaded time zones and formats to choose from.
The inputs for this action are: Base time: Use the output from the Current time action Source time zone: Make sure to select Coordinated Universal Time Destination time zone: Select your local time zone or the time zone you want Format string: This dropdown has many ISO formats to choose from. If you want to have a custom format, simply click the drop down and select Enter custom value. See below for examples
Format Examples
If for some reason the format you want is not in the dropdown for formats, you can create a custom format as long as it follows ISO 8601 format. To add a custom format click Enter custom value in the dropdown
Some tips when creating a format for the date ‘2020-10-13‘ (October 13 2020) yy = 20 yyyy = 2020
Controlling when your Flow triggers can be crucial. By default Flows run in Parallel, this means multiple runs could be running at the same time, this is great for performance, but could cause troubles in some Flows.
Summary
Controlling when your Flow triggers can be crucial. By default Flows run in Parallel, this means multiple runs could be running at the same time, this is great for performance, but could cause troubles in some Flows. For example:
Lets say we have a Flow setup that is triggered on when an item in a SharePoint list is created, which gets sent to other systems for different purposes. For data quality reasons, we only want the Flow to run one at a time, and have other runs be waiting in a queue.
The Flow
The only setting we need to change is in our Trigger.
This can be done on Triggers other than SharePoint
For this demo, I added a Compose action to get the Name of the item being created in SharePoint.
I added a Delay action only to show what happens if multiple runs queue up.
The setting we want to change is in the trigger, click the 3 dots on the trigger and select Settings from the drop down.
Now inside Settings, find and enable Concurrency Control, and set Degree of Parallelism to 1. This setting is how many runs can run in at one time. Click Done
My trigger is When an item is created, so I will create 3 items, one every 15 seconds to show what happens with queued runs. 1st item = Run1 2nd item = Run2 3rd item = Run3
Here are my findings:
As we can see the runs are not in order, of the way I created the items. So we can conclude that if we create the items faster than our trigger time, we can expect that the Flow will not run in a sequential order.
Conclusion
As we can see above, this Trigger setting is very useful when needing to limit the Flow to run one at a time. But the limitation on this is, if the Flow is being triggered multiple times and having the runs queue up, there is a chance that the runs will not run in order.
Using Azure Key Vault to pass in secrets into Flow for secure transportation of sensitive information
How are you using and storing sensitive usernames and passwords in Flow? We use usernames and passwords for so many different actions in Flow. One main use is in a HTTP action.
In scenarios like this, where do you store these usernames and passwords? This post will show how to use Azure Key Vault action to get a secret, which can be passed to any action securely using Secure Inputs and Outputs.
Prerequisites
Azure Subscription
Azure Key Vault setup
Key Vault Permissions set to Get and List Via Access Policy
Key Vault Secret created
Premium License for Power Automate
Steps
Okay, now that we have the above prerequisites ready, lets get the Flow created
First we want to search for ‘Azure Key Vault‘ when adding a new action in our Flow. We will use the ‘Get Secret‘ action
When creating the connection, you will be asked for the Key Vault name. This is the display name that is in Azure.
Next, we add the name of the Secret we want to get. I also Initialize a variable to store the Secret in for easier reference later in my Flow
Inside the Variable, I select the Dynamic content Value.
Now, I run the Flow…
Oh Uh, that doesn’t look good.. Our Secret is wide open and visible in the run history. We can easily fix this.
On the Get secret action we want to enable Secure Outputs We do this by: Clicking the 3 dots on the Get Secret action, Go into settings, Enable Secure Outputs. Click Done
Now when we run then Flow, the Secret value will be hidden from the run history, in all actions.
Thanks for reading!! If you have any questions, please reach out.
In this post, I wanted to share some of the tips and tricks that I have learnt and came across. Some of these tips I will cover the basic fundamentals so you can start using them to help you build you Flows with less pain and more fun!
1. Compose
Compose actions, are one of my favorite actions to use. They are so robust and can display pretty much anything. Compose can be found under Data Operation > Compose
1.1
Add a Compose action before a Condition to check what values are being evaluated. In this example, my condition is saying: If length of value is greater than 0 I add a Compose action before the condition, with the same value I am using in the condition. This allows me to check the run and see the value being evaluated Example:
1.2
If Flow is spitting out errors about a wrong data type or you keep getting unexpected values – Since Compose can hold just about any data type. We can add one and check what the value is in run history.
1.3
Compose actions are great for doing expressions – We can add a Compose action and do expressions in the input, instead of writing the expression directly inside another action. This is handy if you need to do multiple expressions, or error checking.
2. Meaningful Names
There is nothing worse than leaving the default names for all your actions. This can be confusing, which can cause errors which could have been avoidable. This tip is going off tip #1.
2.1
The picture below shows a bunch of Compose actions Left: Default names used – Makes it very hard to know which action is what Right: Custom names used – Changing the names to something meaningful allows actions to be easily found and referenced.
2.2
For awhile now, Power Automate has had a limitation with renaming actions that were being referenced in other places. That has since changed. We can now rename action that are being referenced in other actions! For example: The left picture shows the Compose action named ‘Compose Project’ and is being referenced by the condition below. Changing the Compose action name to ‘Project Name’ also changes the name in the referenced condition, which is shown in the right picture.
—–NOTE —– Limitations still exist.. The reference will not be updated if the action is in a expression OR inside a Loop. And will throw an error of: Template Validation Failed. So it is always best to rename actions right away —————
2.3
When using Expressions, to better understand and show others what is going on. Comments are great for this. For example, if using a complex expression I like to copy the expression and put into a comment of that action:
3. Scopes
Scopes are handy, they can be used for grouping actions together. In this guide I will show how to use scopes to group actions together. There are many advanced techniques that scopes can be used for, but for this demo I will be showing the very basics. Scopes can be found under Condition > Scope
I will add 2 scopes, one for Users, and one for Accounts To add actions in the scope, Click and Drag the action into the scope
Drag the actions in so the order of the actions remain the same. For example, I put the Scope above the List Records action so I could drag the List records in first than the For each loop next
This concept will help us in the following tips
4. Parallel Branches
All Flows run from top to bottom in a single order fashion. If we split the actions to run side by side (parallel) This would drastically improve performance. In this scenario I have Two(2) CDS List records, and Two(2) Apply to each loops
List Records – Users Apply to each – To Append(add) all First names into a single variable List Records – Accounts Apply to each – To Append(add) all Account names to a single variable
Here is what the Flow looks like:
Running the Flow, we can see it takes about 4 minutes
Before we create a parallel branch we first must put the actions inside a Scope, this is to allow us to drag the actions around without getting the
This action cannot be dragged above actions it depends on. Error
Refer to Tip# 3 for details on Scopes
Now lets have these 2 different Scopes run in parallel branches First we want to click the ‘+’ icon where we want to add the branch, next click Add parallel branch
In this example, I am adding a parallel branch above both Scopes
Our screen will look like this:
Next we need to Click and Drag one of the scopes to the new branch
Once the Scope is in the branch we can click the X on the Choose an action tab
Now lets run thew Flow again: As the picture below shows, the Flow now only takes 2 minutes to run, cutting our run time by half, that’s insane!
Imagine our run normally taking 30 minutes, now only taking 15, just from a simple step
Tip# 5 will make our Flow run even faster!!
5. Concurrency
What is it? By default loops run one after another. Concurrency can make loops run in parallel. To better understand this, we can think about a grocery store. In this scenario:
People = Value that is going into Apply to each loop Lanes/Cashier = Concurrency Control Number
There are 20 people waiting in line at the store. There is 1 lane/cashier open. Since the cashier can only take one person at a time, this process can be lengthy. Now with Concurrency turned on, things are a bit different. Lets say we set Concurrency to 5. This means 5 lanes/cashiers will be open. This is great! But there is a catch..
When Concurrency is enabled, there is no more line. All 20 people are processed randomly.
Concurrency can be applied to all Apply to each loops — As well as Triggers!
To enable Concurrency:
First, click the 3 dots on the Apply to each action Next, click settings
Next, choose the value for Concurrency and click Done
For this Demo, I am setting Concurrency to 50. Please be aware of API limit calls and 429 errors. If you get these errors while flow is running. Decrease the Degree of Parallelism
Now lets see this in action! I set Concurrency to 50 on both my Apply to each loops from the last Tip. As a recap, the last time we ran the Flow, it took 2 minutes to run.
Results: About 5 seconds!
The Run time is about 5 Seconds. Since we used a Parallel branch the total run time is the longest duration of our Parallel branches
This drastically improves performance.
Conclusion / Key Take Notes
Use a Compose action to check values and outputs, that you normally cannot see, Like in a If Condition
Compose actions can store almost any data type. When in doubt.. Use a Compose
When using expressions, try using them in a Compose, this can make troubleshooting much easier
Always use meaningful names for all your actions. Doing this will save loads of time later on, when needing to use dynamic content
Comment, comment, and more comments. All actions allow for comments. This will help support teams troubleshoot your Flow, as well as your future self, if you have to make any updates later on
When using expressions, copy the expression and paste into the actions comments section.
Use Scopes to group actions together.
To speed up performance, use parallel branches to enable actions to run side by side
Enable Concurrency control on Apply to each loops to drastically increase performance
Remember enabling Concurrency control randomizes the order the loop iterations run in. So if you’re expecting a certain order processing to happen, do not enable
These are some of the tips and tricks I wish I knew sooner. I hope at least one of these tips and ticks have helped someone. Thanks for reading!
We will be adding a Security Role / Field Security Profile to users in CDS. For this demo, our scenario will be grabbing all the users from a Office365 group and assigning them a certain Security Role / Field Security Profile.
The source of the users can be from anywhere: – MS Form – SharePoint – Array inside the Flow – Excel Table – AAD Group / Office365 Group
Prerequisites
We will be using the Common Data Service Current Environment connector. This means that our Flow, MUST be created inside a Solution.
You will need appropriate permissions to be able to assign Security Roles and Profiles to
Steps
INFORMATION: This Flow will work the exact same to add Field Security Profiles instead of Security Roles. The only changes you have to make are in the List records – Get Security Role, and the Relate records – Security Role to User. The changes are listed in the captions of those images.
We use a Variable to store the name of the Security Role we want to add to the users. Than use a List records action on the Entity Security Roles In our Filter Query we will use: name eq ‘ ‘ Since we are using a variable to store the name of the Security Role, we pass this into the Filter Query
Field Security Profile = Change Entity name to Field Security Profile
Next, add a Compose action, to get the Odata URL. This URL is how we will add the Security Role to the User later on.
1) Inside the Compose action select Expression tab 2) Use the expression first() 3) Click back to Dynamic content tab
We use first() to get the first value in the CDS List records action. This allows us to bypass the Apply to each loop that Flow creates for us
4) In the ( ) select the Dynamic content value from the List records action
TIP: Make sure you see the fx logo in the text box, this indicates we are using an expression
5) At the end of the expression add:
?['@odata.id']
6) Click OK
7) Confirm the expression saved correctly by hovering your mouse over the expression
Next, use any data source / connector that meets your needs to get the emails of your users that you want to add – In this example I am using Office365 List group members
Add an Apply to each loop – So we can loop through each email and assign the Security Role
Inside the Apply to each loop, add a List records action on the Users entity Filter Query = internalemailaddress eq ‘ ‘ Add your dynamic content that has the email address for the user to add inside the ‘ ‘
Next, add a Compose action – to store the User ID (Unique ID) We use the same technique as mentioned above, using first() and the field name Add this to the end of your expression
?['systemuserid']
systemuserid = the field name in CDS that stores the Unique value for each user. This value is used as a lookup guid. So we can relate the records to this guid
Still inside the Loop: Add a Relate Records action.. This is one of the actions inside the Common Data Service Current Environment Connector. Entity Name: Users Item ID: The Compose – Get User ID Outputs Relationship: Select ‘Security Role – systemuserroles_association’ from the drop-down URL: The Compose – Security Role odata URL
Field Security Profile = Change Relationship Dropdown to — Field Security Profile – systemuserprofiles_association
Your action should look like this:
Conclusion
Adding Security roles or Field Security Profiles, can be a long and tedious process. You can add this Flow to a MS form and have users fill out what roles they need.
Basically, we want to be able to control if we want an error. At this time Flow does not let you easily throw an error.
There is a Terminate action which is awesome, I use it in every Flow or Logic App I create. The Terminate Action will terminate the Run immediately. Terminate will not allow other actions to execute, even if the ‘Configure Run After’ is set to Failed, Skipped.
This can be a headache trying to implement a way to easily Fail an action. While allowing the Flow to continue running the ‘Configure Run After’.
Setup
We will use a Try – Catch method. Basically we will use ‘Scope’ actions to house different parts of our actions. You can think of ‘Scopes’ like a way to organize your Flow. Add them into your Flow just like any other Action.
Try – Where your original flow design will be placed. Catch – This is where we ‘Catch’ – Meaning we will only run this Scope if the above Scope has a Failed Action
First add a ‘Initialize variable‘, define the type as Boolean, and call this variable Exception. Next add two(2) ‘Scopes’
Next we want to only run the Catch Scope, if the Try scope has failed. To do this, simply click the Three(3) dots on the Action and click ‘Configure run after’
Now deselect ‘is successful’ and select the ‘has failed’, and ‘has skipped’ checkbox. Click Done
Next, to trigger an error in the Try Scope, add a ‘Set Variable‘, and select the Boolean from above.
Now, inside the value use the expression null.
The Set Variable should look like this now:
Since our Catch block will run if Try fails, our run will show as Successful. We can change this by adding a ‘Terminate’ action
Add any other error handling you wish inside the Catch scope, some examples include:
Email to Support that Flow has failed
Different type of business processing
Delete a record
Rename a record
Service Bus – dead lettering
TIP: When adding other actions inside the Catch scope make sure to make the Terminate action last
Here is a Test run:
Conclusion
This is a great method for executing an error, Its fast and simple, and can be used many times in the same Flow. Thanks for reading!
Microsoft Forms is great for many use cases. However, with some use cases you may not want the whole organization to have access to this form.
Summary
In short, we want to setup a way to allow certain users to fill out a MS form. How can we achieve this? My Flow below will show how to take a list from SharePoint that has users emails, to only allow them to process the Form.
** Note – You do not have to use SharePoint, you can use any means necessary. **
Setup
First you will need to have a Microsoft Form created – Any MS Form will work
Next, we setup our List of ‘Authenticated’ Emails. Again in this demo I am using SharePoint I created a simple SharePoint List with a single text field to store email addresses
Steps
In the Flow, we create as normal with a Microsoft Form Trigger and action to get the Details Trigger – When a new response is submitted Action – Get response details Next add a Variable, we make the Type an Array Under the Variable, add Get items action, and choose our Authenticated users list that we created above
Next, add an Apply to each loop. Select the value from the Get items action. Inside the loop, add a Append to array variable, select the variable that we initialized above. Value = the column name that stores the email Address in our SharePoint List
** Note – Make sure the Initialize variable is type Array **
Outside the loop – Add a Condition Select the Array on the left side – Contains – Responder on the right
— We use Contains to check if the User filling out the form is in this Array of emails —
If the user who is filling out the form does not belong to the ‘Authenticated’ list, we Send an Email letting the user know they are unauthorized to fill out this form. Under the Send an email action, add a Terminate action with Status of Success, this is to ensure the flow stops running, while not throwing an unwanted Failed run
Here is what a User will see when they do not have access
Conclusion
I am sure there are a million ways to add your own intuitive Authentication methods. I hope my method helps or inspires someone else! Thanks for reading
Have you ever noticed that Power Automate will sneak in that ‘Apply to each loop’ even though you are only expecting a single value.
For example this can happen whenever you are using a Action that ‘Lists’ items, folders, fields, etc.
In this example I will be showing how to get a User ID in CDS with the users Full Name.
Have you ever noticed that Power Automate will sneak in that ‘Apply to each loop’ even though you are only expecting a single value. For example this can happen whenever you are using a Action that ‘Lists’ items, folders, fields, etc. In this example I will be showing how to get a User ID in CDS with the users Full Name.
The Problem
Power Automate creates a ‘Apply to each’ loop when selecting dynamic content from a action that Lists items, folder, or anything. In most cases this is awesome and creates a nice smooth workflow.
However, what about when you know exactly what you want to look for and you know its only going to be 1 record, item, whatever is going to be returned. Power Automate will still make you use the ‘Apply to each’ loop.
This may not be a such a terrible thing, but if you need to do multiple things underneath that action, you will have to put them in the loop as well (if you need any data or reference to that action)
The Solution
On to the magic.. In my example Flow I will be using:
‘Compose’ action to have my Full Name stored.
‘List records’ CDS action to list records from the default Users table entity. ** Note – This can be done with any connector. **
ODATA filter on the ‘List records’ which I am using to filter ‘fullname’
Under the ‘List records’ I use a ‘Compose’ action to store the users ID(Primary Key from CDS) and the users Email Address
Step 1 – I am using CDS List records for my example, with a Odata filter
My List Records with my Odata filter
Step 2 – Adding Compose action to use the Expression to bypass the loop
Add a Compose action below the List action. And select Expression
Type anything, this is to keep us in Expression mode when we switch back to Dynamic Content tab
If you see the fx Logo in the Dynamic Content Tab, you have done this correctly
Remove what you had, and Click the Value of the action you want to bypass the loop with
Remove the ? and add [0] This is saying we want the first record only. Since this returns an array we say 0 as this is the first record in an array
after the [0] we type what the field name is, in this format: [‘feildname’]
Click OK.. I usually like to put the Expression in a Comment
This is the exact expression I used in my Compose action
body('List_records')['value'][0]['systemuserid']
DONE!
Limitations:
The only thing you have to watch out for is when there is a empty record. This will cause an error if the record is empty. This can easily be fixed using a Condition If block before the Compose to check if value is empty using the empty() expression. OR If you want to avoid the error altogether, you can use the expression first() instead of body()
I hope anyone finds this useful. This boosts performance greatly when you only need one record since you wont need a Apply to each loop.