Showing results for 
Search instead for 
Did you mean: 

PowerApps Workflow Processes Part 1: Introduction



PowerApps is fantastic at creating business applications FAST. Imagine the power of using this same platform to drive multi-step business processes, involving various roles, steps, and routing options. This article is the introduction of a 3 part series that will discuss PowerApps Workflow Processes.


PowerApps Workflow Processes Part 1: Introduction <<== You are here

PowerApps Workflow Processes Part 2: Using Microsoft Flow

PowerApps Workflow Processes Part 3: Using a third party BPM engine


*This article assumes an intermediate understanding of PowerApps.

**Please don't pay too much attention to the formatting of the examples, they are just examples Smiley Happy


Also, watch out for an online Webinar about PowerApps and BPM with Audrie Gordon on 23 April.





Workflow (or Business Process) is an orchestrated sequence of steps to achieve certain tasks, goals or outcomes. The sequence is well planned to ensure that each role player has the right information at the right time to perform the actions that are required from their step in the process. At each step, the responsible user will have options that are used to progress the process to the next relevant step.


A good example of this would be a Staff Onboarding process. Depending on your business rules, the Departmental Manager might initiate the process by requesting for a position in the team to be filled. This request (with motivation) will be sent to HR for review and if approved, to kick off the recruitment and interview processes. Once the position has been filled, the same process can then be used to prepare all the work tools (phone, notebook, parking etc) for the new joiner. You might then also want to automatically welcome the new employee to the company on the first day with clear instructions on tasks that they have to perform to get up to speed in the shorted possible time.


If you don't have a proper process in place, the above activities would probably involve various back and forth emails of people trying their best to make sure that things get done at the right time. No matter how hard they try, without a proper process, the new employee will in most likelihood run around on their first day (or maybe longer) trying to get his\her work tools organized. In short, users should not use email to drive Business Processes but Business Processes might use email to notify users of the next step of the process. Not having a proper process has the following disadvantages:

  1. Employees have to remember who to email their requests (and subsequent follow-ups) to.
  2. An unmeasurable amount of time and resources (well, unmeasurable until you have to present ROI figures as motivation for improving your process) is wasted by people sending requests to the wrong people. This frustrates everyone in the process only to end up with 10 people in a CC address field, or even in the much dreaded BCC!
  3. Various different versions of information are spread throughout multiple email boxes. This will keep you nice and busy just to try and find out what the latest status of a request is.
  4. It is impossible to have consistent experiences for employees, clients, and other stakeholders as the process is 'invented' every time. This leaves massive chances for oversight and huge headaches for anyone who likes structure and predictable outcomes.

Sold on proper processes yet? If you are, let's discuss how this can be achieved. If not, close this article and go spend some good time to find out what the status of your last expense claim is.


PowerApps Workflow Processes


In its most basic form, the front-end will contain fields that users input or select data into, and options that users use to action their workflow step and direct the workflow to the next step. Depending on the current step in the process, certain fields might be hidden or locked and only certain options should be displayed to the user. If you are submitting an expense claim into the process as an example, you would not want the originator to see the Approve option button and you might not want the approver to be able to update the requested amount. To achieve this, there are basically 3 ways to simulate the Business Process in a front-end system. This is not only true for PowerApps, but for most systems and processes.


Multiple Screens


The first option is to create multiple screens in the application, to make sure that the user only sees the fields and options relevant to his or her step. With complex multi-step processes, having multiple screens could become quite cumbersome as this would mean that most controls are duplicated on each screen. This not only creates a nightmare for the person creating, or maintaining the app, it could also dramatically affect performance for the app if it is loading 20 screens, each containing 100 controls with '_1_1_1' as control names.

And then, at 99% project completion, the process owner tells you that he loves the new app, but that 2 additional fields should be added. Guess what, you have to now update 20 screens with the new fields, as well as worry about spacing and formatting on all the screens, essentially duplicating effort for each step. The below only has a few screens to give you the idea. I was planning to create 20 screens but I got bored with so much repetitive work so I started paying with the dog.


Multiple Screen Example.png


Single Screen - Lots and lots of formulas


The second option is more efficient for processes with many workflow steps, but involves quite a bit of formula and logic to be placed on each control and option button. The Visible and DisplayMode properties for fields and action buttons can now be controlled with formulas to simulate the screen for the specific step in the process. The biggest problem with this is that the formulas behind each element can become quite scary, and it might be difficult at times to make sure that the correct person only sees and edits what is expected from them. If you decide to use this method, resist the temptation to use any formulas that are hardcoded to a person's name in Visible and DisplayMode properties. If you see 'If(User().Email="Mike Rambo",....,.....)' somewhere in the formula, know that you are probably in for a tough time.


Single Screen Example.png


Single Screen - Profiled Workflow Process


The idea is not to mix process, controls, and data. If you can tell the application how to behave according to which workflow step the user is currently in, without hardcoding the process into the form, this would be the first prize and would allow for an agile system. This system would be easily updated in future as business requirements changes, without introducing a long string of bugs and hair loss. We all agree that business of the future will have to be agile, so hardcoding apps in the organization might cause more harm in the long run than you realize. How do you profile the business process you might ask? Microsoft Flow can be used to create basic approval flows, but does not cater for processes that have many different complex steps which that might be open for a long time.

What we were able to do though, is use flow to serve a JSON Business Process rule set to the PowerApp through an HTTP request. 


JSON Workflow Profile.png


We then use the visible and display mode property on every field to be visible or editable based on the rule set that it receives from Flow.


Visible Formula.png


DisplayMode Formula.png


Instead of hard-coding buttons on the screen to give the users options during the step, we can now display the options from each workflow step as defined in the JSON profile.



A submit button is then used to execute the selected option and call Microsoft Flow to trigger the backend actions, like determining what the next step is, updating workflow history, and sending email notifications to the next responsible person.




The Flow run can also be used for integration to other systems, and to determine the different roles in the organization based on various factors. The Flow connects to the JSON Workflow profile through the webhook, and to the SQL data and SQL workflow history tables before processing the calculations for next steps and responsible people.


Flow Submission.png


A workflow history could be stored for audit and track and trace purposes.


workflow history.png


Sadly, there is no way that we can find to pass evaluation formulas to PowerApps, so to profile business rules outside of the PowerApp is not yet possible. I am sure this will come in future, but in the meantime we can use a switch statement on the submit button before calling the submit Flow, to determine which Step and Option are being executed, to inform the user of any validation checks that fail. The good news is that you can specify rules in the app, and then just reference then in your submit button.




If in future Flow can also provide feedback to PowerApps when being called from PowerApps, Flow will also be handy for validations. (Click here to vote for this idea with Microsoft please please please)


The next article will discuss the above in details while the 3rd one will demonstrate what can be achieved if PowerApps is linked to an enterprise microservices BPM engine.



VS Code: