Conditional logic and validation
1. Conditional logic and validation
A form that lets users submit blank or broken records creates support tickets for itself. This video is about teaching your app to refuse bad input: preventing the bad submit, correcting it after the fact, and showing or hiding controls based on what the user is allowed to do.2. Conditional formatting (recap)
A quick recap. If is the workhorse function: you give it a condition and two outcomes, one for true and one for false. You met it in Chapter 2 coloring gallery rows by priority. The same shape powers everything in this video: validation, prevention, and showing or hiding controls.3. IsBlank(), catching empty fields
The basic validation building block is IsBlank(). Pass it any control's value or any data-source field. It returns true when the value is empty, missing, or default. So IsBlank(DataCardValue1.Text) is true when the user hasn't typed anything into the Title card yet. This single function powers the two patterns we'll meet next: prevention and correction.4. Prevention: DisplayMode
Prevention is the friendlier of the two patterns. You set the Save button's DisplayMode with IsBlank inside an If, as the slide shows, so the button is disabled while the Title field is blank and editable once it's filled. The grayed-out button means the user simply can't submit a broken ticket. To require more than one field, combine the checks with Or, disabling the button whenever any required field is still empty.5. Correction: Notify() after submit
Correction handles the cases prevention can't catch: validation that only fails on the server, network errors, or business rules enforced by the data source. You wire the form's OnFailure to a Notify call with an error style, as on the slide, and a red message appears briefly at the top of the screen. NotificationType offers four styles: Success, Error, Warning, and Information. Use Notify together with prevention, because on its own it can only speak up after the user has already tried to save.6. Visible versus DisplayMode
Two properties look similar but behave very differently. Visible = false removes the control from the layout entirely, so other controls flow into the gap and it drops out of the tab order. Use it when the control is irrelevant to the user, such as a manager-only section. DisplayMode.Disabled keeps the control in place, grayed out and read-only, for when the user should see it but not interact with it yet. DisplayMode.View is the equivalent for read-only fields inside form cards.7. A concrete example
A real screen often uses both rules. On a ticket detail screen, the Approve button is visible to every user, but its DisplayMode is Disabled until the required fields are filled. Below, a Manager-only section, with approval notes and budget impact, has its Visible set to an isManager formula declared in App.Formulas. Technicians never see it at all. One screen uses two different properties for two different reasons.8. Server-side vs client-side
Client-side validation is what we just built with IsBlank, DisplayMode, and Notify. It runs in the user's app, and its job is user experience: stop bad submits early and explain clearly when one slips through. Server-side validation is SharePoint's required-column setting, or Dataverse's table rules, and its job is data integrity, refusing a bad row no matter how the request arrived. Use both, and remember that Power Apps formulas are not a security boundary. DisplayMode.Disabled and Visible = false help the user, but they don't stop a determined actor from writing to the data source directly.9. What you'll build
In the exercises you'll teach the form to refuse bad input, and see how an error message warns the user when something slips through.10. Let's practice!
Time to make your form refuse bad input.Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.