In PowerApps, once you get beyond the basics of customizing SharePoint list forms, or just using the out-of-box form control in your apps, the next common thing that people like to do, is add some logic to their forms. In this post and associated video, I’ll demonstrate some of the most common things that are done with form logic, and how to accomplish them in PowerApps. First of all, in PowerApps, we have a control called the “form control”. If you have created your app as a customized SharePoint list form, you already have one screen with one form control on it. If you’ve created a standalone app (which I highly recommend), the form control is something that you will be adding to your app. See my other blog post about standalone apps versus customized list forms for more info about that topic.
Here’s a form control that I added to an app, arranged the cards like I want them to look, and added a big Submit button, and a lovely purple rectangle at the top.
When creating logic in forms, this is usually done on each card. Cards represent each field (column) in your SharePoint list or library.
Understand that there is a parent-child structure. Cards can reference their parent (the form) and controls in a card can reference their parent (the card).
Common Logic: Editable field according to condition
The display mode of a card can be set using the DisplayMode property, and here are some examples of what the 3 display modes look like, with a date picker control.
Edit: The value can be edited by the end user filling out the form.
View: The value is read-only
Disabled: The control is grayed out and read-only.
Side note: The way a control looks when it is disabled, can be controlled using any of the properties related to disabled controls. Here, I did a search of properties for this date picker, in the advanced tab:
By default, each card inherits some of its parent’s properties. DisplayMode is one of them.
Here’s how the logic works,with an example:
Goal: Customer Status is read only for new forms. My form is named frmNewCustomer. First, unlock the card. (on the advanced tab on the right)
If the mode is new, THEN
This second one is a little more advanced. I added the Office 365 Users connector to my app, to gain insights about users. For this logic, I’m assuming that if you have direct reports (based on user profile data) then that means you’re a manager, otherwise, you’re not a manager.
Goal: Customer Status is disabled if the current user is not a manager
IF the current user has no direct reports, THEN
Common Logic: Show / hide field according to condition
Every control has a Visible property, which is a boolean (true/false). Logic can be used, to conditionally show and hide anything.
Goal: The hours used field should only show if the project status is complete. My control that has a drop-down for project status has been named drpProjStatus. This formula is placed on the visible property of the hours used card.
Common Logic: Required field according to condition
Every card has a property called Required, which is a boolean (true/false). Logic can be used, to conditionally make a field required. Note that if this logic is used, make sure that the field is not set as “required” in the list settings in SharePoint.
Goal: If estimated cost is greater than $5,000, the manager field is required. This formula is on the Required property of the manager card.
Using those principles, and understanding how IF statements work, you’ll be able to built any logic that is needed in your apps.
Here is the video where I demonstrated these methods during Power Hour:
Are you brand new to PowerApps, and interested in getting started learning some fundamentals? Try out my
Beyond beginner? Check out my full (12 hour) PowerApps advanced training class!