You probably know that you can trigger an associated Flow from a PowerApp. You didn’t? Well you know now!

But did you know that PowerApps and Flow can work in perfect harmony after configuring your PowerApp and Flow correctly?

In this blog, I will explain you how to achieve this.

By default, there isn’t much communication between PowerApps and its associated Flow. The only way they ‘communicate’ is that the control that triggers the Flow will be disabled until the Flow has completed.

I will explain 2 ways that will harmonize your PowerApp with its associated Flow:

  1. Disable PowerApp controls while Flow is running
  2. Push Flow status to your PowerApp

By default PowerApps will only disable the control that triggered the Flow, but in some cases you want other controls to be disabled as well.

To do this, you must initialize a variable on the OnStart event of your PowerApp and set its value to false.

Set(
    flowRunning,
    false
)

Now select the control which triggers your Flow. In this example, my Flow is called ‘PowerAppsbutton’ and has no input parameters so the OnSelect property of this control is:

PowerAppsbutton.Run()

This needs to be altered; before your Flow will be triggered, the flowRunning variable needs to be set to true. When the Flow has completed, the flowRunning variable need to be set to false again:

Set(
    flowRunning,
    true
);
PowerAppsbutton.Run();
Set(
    flowRunning,
    false
)

Now we need to disable the controls by setting the DisplayMode property to Disabled when the Flow is running. We can do this by checking the flowRunning variable by using the following function:

If(
    flowRunning,
    Disabled,
    Edit
)

Now when we run the Flow, not only the trigger button is disabled but also the other controls that we’ve configured:

When a user click the button to trigger a Flow, it would be nice that the user will be informed on the status on the Flow progress. Both during the Flow run and after the Flow run.

During the Flow run

The only way the user can see that the Flow is still running is because the control is disabled, but that’s not what most users are used to because they would like to see a progress bar of some kind.

You can do this by adding a spinner image and set its Visible property to the flowRunning variable we created in our previous step. When the Flow is running, the flowRunning variable is set to true and so will the Visible property be. When the Flow has completed, the flowRunning variable will be set to false again and the image will be hidden again.

After the Flow run

When the Flow has completed, all of your controls are enabled again but the user doesn’t know exactly what happened. By giving the user insight into the result of the completed Flow, the user can decide what the next step will be.

To do this, we need to perform a few steps:

  1. Initialize a string variable at the beginning of our Flow in which we will store the result of the completed Flow.
  2. Place all Flow process actions into a Scope (which is basically a container of actions). The Scope can be found within the Control connection or by searching for Scope
  3. Add three parallel ‘Set variable’ actions after your Scope in which you set the value of the results variable.
    • Set the value of the first Set variable action to ‘Success’
    • Set the value of the second Set variable action to ‘Error’
    • Set the value of the third Set variable action to ‘Timed out’
  4. Add a ‘Respond to PowerApps’ action after the parallel branch and add a Text output called result and place your result variable into the value (via Dynamic Content)

Your Flow should look like this now:

Now we need to configure the Flow that only the appropriate Set variable action will run (Succeeded, Failed or Timed out) by selecting the ellipsis symbol (three dots: …) on your Set variable action and selecting Configure run after. This will allow you to only run a specific action when a certain condition is met (e.g. when an action or action set has failed). More information on this can be found here.

Make sure to configure these settings as follows:

Finally, we need to configure the Configure run after setting of our Respond to PowerApps action so that this action will run if one of the Set variable actions is succeeded and if the rest is skipped. This is because only one of the Set variable actions will be triggered. All other Set variable actions will be skipped. If you don’t edit the default Configure run after setting of the Respond to PowerApps action, it will not run because the default setting expects all of its previous action to succeed.

You can set the values of each predeceasing action separately by clicking on it and checking its appropriate values which are is successful and is skipped. Make sure you set each Set variable action seperately!

Now that our Flow responds the result back to PowerApps, we need to make sure we show this result somewhere. This result is part of the <flow>.Run() action, so we need to store this record into a variable first. To do this, we need to alter the OnSelect property of the control that triggers the Flow. We already changed it in the first part of this blog (by setting the flowRunning variable before and after the Flow run), so we need to change it one more time.

The PowerAppsbutton.Run() part needs to be replaced into the following:

Set(
    powerappsResult,
    PowerAppsbutton.Run()
);

So our full OnSelect function is now as follows:

Set(
    flowRunning,
    true
);
Set(
    powerappsResult,
    PowerAppsbutton.Run()
);
Set(
    flowRunning,
    false
)

Now we can add a label and set its Text property to powerappsResult.result. We can also play around a bit with the font color of the label and only show it when the Flow is not running (by setting the Visibility property to the opposite value of our earlier configured flowRunning variable by using !flowRunning (when using a boolean variable, you can call the opposite value by using an exclamation mark). So when the Flow is running, the flowRunning variable value is true which means the Visible property of the status label will be false.

Previous articleJan de Vries – Binding your serverless clients
Next articlePowerApps and managed metadata
avatar
My name is Rik de Koning and I work as a Functional Consultant for Portiva, which is one of the larger Office 365 implementation partners in The Netherlands. I started my career in 2011 as a SharePoint support engineer and in 2013, I went to become a SharePoint consultant where I did various projects on SharePoint Server 2010 and SharePoint Server 2013. In the last couple of years I started focusing more and more on Office 365, especially on SharePoint Online, PowerApps and Microsoft Flow. I like being challenged and for PowerApps and Flow being quite new, there are always some challenges when implementing these services. When I’m not working, I like spend some time with my family (girlfriend and son), hang out with friends, do some sports (like fitness, running, kitesurfing and snowboarding) playing videogames and just relax a little. If you have any questions, please do not hesitate to contact me!

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.