More than often we make use of the Ask in PowerApps property. You know, this one:
When you use the PowerApps trigger you can hardly get past this property. Somewhere down the line it is almost certain that you will need to retrieve data from PowerApps via this property.
Very often I encounter a configuration where the data to be retrieved is directly queried from the field:
In PowerApps the Flow will then be depicted as follows:
I admit, through time I have grown quite fond of the possibilities this property offers. But I have also experienced some odd behavior. Let’s say for example that instead of querying the field directly, I. want to query the data indirectly via a Compose action. So, I modify the existing flow to this:
You would expect the changes to be reflected in PowerApps like this:
Instead I get to see this in PowerApps:
As you can see, the previous properties are still present! In my experience the only way to get rid of these old properties is by …uhmm… recreating the Flow entirely! But maybe someone knows a better method….? If that’s the case, please let me know.
In the case of a non-complex flow, you can rather easily re-create the Flow. But what if this is a complex scenario…. then you’re stuck!
It is -or was if this is already fixed- this odd behavior that led me to develop my own best practice when it comes to this function.
And what is my best practice? I use a single compose action to retrieve all the necessary data from PowerApps. Then I use Microsoft Flow’s capabilities to split, format and extract the data.
Of course, there will be situations where you’ll need to make use of multiple compose actions. But as you might guess I try to avoid this as much as possible.
The first step is creating a concatenated string of all the data fields in PowerApps which includes the “|” delimiter as the separator. In this case it would be something like this:
This results in:
If the data to be captured is already in a collection, I concatenate this into a string, and then I set the string as a global variable to be used in the Flow. For such scenario, I’ll write a follow-up blog post.
The Flow to be used is something like this:
In PowerApps this translates to:
That’s a big improvement isn’t it?
This:
Instead of this:
What are the benefits of this approach?
- Simplified Flow syntax in PowerApps. Only 1 parameter required instead of multiple.
- Delegating the splitting, formatting and extraction of data from PowerApps to Flow. Thus, exactly what Flow is designed for in the first place!
- As all the data formatting, splitting etc.. is being delegated to Microsoft Flow, the output can be easily modified by applying the necessary changes in the Flow. No more modifications in the PowerApps solution itself. 😉
About the Author:
Clifton is a Microsoft Business Applications Solutions Specialist focused on the Power Platform. In daily life he works as a Functional Solution Consultant and Techno-Functional Lead for the Power Platform at Ordina Group, the largest Independent IT Services Firm in the BeNeLux.. He’s been in IT for over 15 years; mostly in an Infrastructure role. Over the last 5 years he’s shifted his focus focus to the Business Applications realm. And that’s how he ended up being a Board Member and Co-Founder of the Belgium PowerApps & Flow User Group.
Check out his LinkedIn here.
Reference:
Lenne, Clifton. (2019). How I use the “Ask in PowerApps” property efficiently – Part 1. Available at: http://www.yait-c.net/how-i-use-the-ask-in-powerapps-function-efficiently/ [Accessed: 10th April 2020].
Find more great Power Platform content here.
