Typically in every Power Apps solution we implement we need to provide feedback to the user if he or she has entered invalid information in one of the fields on the form or skipped filling in a required field altogether. I have used various ways to acchieve this throughout dozens of apps I’ve implemented in recent years and in this post I’ll introduce the one I like the most.
Let’s say we have an imaginary mobile app consisting of three screens:
- Basic input controls such as text, dropdowns and dates
- Gallery of items within which the user must make a choice for each of the items
- Submission screen to view the result of the validation and to make the final submission if everything is ok
The app I created for this blog post is really simple and looks like this before I’ve implemented any field validations.
Now, let’s implement some field validations and display an error text next to the relevant field.
Screen 1:
- Validate that the title is at least 10 characters and maximum 100
- Description must be entered
- At least one business unit must be selected
- The date should be in the future, but no further than one month away
Screen 2:
- A required service level for each of the services needs to be selected
Submit screen:
- If all validations are ok, display the green check mark and enable submission, otherwise display list of errors and disable the submit button
On screens 1 & 2 validation logic is implemented so that there is a static red error label next to each field. Each label’s visibility rule is defined so that it complies to the validation logic. For example, Visible property value of the error label below the title input box is simply:
Len(inputTitle.Text) < 10 || Len(inputTitle.Text) > 100
Therefore, the error text is only displayed if the length of the text entered is less than ten or more than hundred. And for the business units combo box, we want to validate that at least one BU is selected:
CountRows(selectBusinessUnits.SelectedItems) = 0
Date validation:
dateDeadline.SelectedDate < Today() || dateDeadline.SelectedDate > DateAdd(Today(), 1, Months)
Validating the selection of the required service level for each of the services listed on the second screen is implemented in a bit different way. We still have a static error label having a text “You must choose required service level for each of the listed services”, but the visibility rule for this label must validate that each listed service has a level selected:
CountRows(Filter(serviceColl, Len(SelectedLevel) > 0)) < CountRows(galServices.AllItems)
Clicking on each service item’s Level 1, 2 or 3 button patches the item by updating the SelectedLevel property:
Patch(serviceColl, ThisItem, {SelectedLevel: btnSelecteLevel1.Text})
Hence, comparing whether the count of items having length of SelectedLevel zero to all the items in the gallery works.
The submission screen looks like below when all the errors are visible.
For that purpose I’ve created a gallery having Items property like this:
Filter([
If(lblErrorTitle.Visible, lblErrorTitle.Text, “”),
If(lblErrorDescription.Visible, lblErrorDescription.Text, “”),
If(lblErrorBusinessUnits.Visible, lblErrorBusinessUnits.Text, “”),
If(lblErrorDate.Visible, lblErrorDate.Text, “”),
If(lblErrorServiceLevel.Visible, lblErrorServiceLevel.Text, “”)
], Len(Value) > 0)
So basically, we create a static collection of error texts and filter that collection so, that only texts having a length above zero are included. Each item in the collection tests whether the corresponding error label is visible and if it is, the label’s text is included in the collection – otherwise empty string is used. In other words, only valid error texts are included in the gallery items.
Whether the green OK icon and text should be visible, we can easily use this formula to check the gallery’s item count (if count is zero, everything is ok):
CountRows(galErrors.AllItems) = 0
And for the submit button’s DisplayMode we can check the icon’s visibility:
If(iconOK.Visible, DisplayMode.Edit, Disabled)
And by the way, the above sort of underlines one of the golden rules I try to follow whenever developing a Power Apps solution: only implement UI logic once and take advantage of that implementation in other places. That means that above the DisplayMode property of the button utilizes another control’s property that already implements the actual business logic to determine the behaviour, that way we need to only make a change to one place if the business logic changes.
Once finished with implementing the error logic, the app behaves as expected and as shown in the short recording below.
terhoantila.com 