Conditional logic and validation
1. Conditional logic and validation
A form that lets users submit blank or broken records is a form that 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. It's worth getting comfortable with that structure, because once it clicks, you stop thinking about it.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 two patterns we'll meet next, prevention (stop the user from submitting) and correction (tell them off after they submit).4. Prevention: DisplayMode
Prevention is the friendlier of the two patterns. You set the Save button's DisplayMode so that the button is disabled while the Title field is blank and editable once it's filled, using IsBlank inside an If, as the slide shows. While the field is blank the button grays out, so the user simply can't press it and can't submit a broken ticket. To require more than one field, you 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 telling the user what went wrong. NotificationType gives you four styles to choose from: Success, Error, Warning, and Information. Use Notify together with prevention rather than on its own, since 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, other controls flow into the gap, and it disappears from the tab order. Use it when the control is irrelevant to the user (a Manager-only section hidden from non-managers, say). DisplayMode.Disabled keeps the control in place, grays it out, makes it read-only. Use it when the user should see the control but not interact with it yet. DisplayMode.View is a related setting used inside form cards for read-only fields.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. Same screen, two different reasons to hide things, two different properties.8. Server-side vs client-side
Client-side validation is what we just built, IsBlank(), DisplayMode, Notify(). It runs in the user's app and its job is UX, stop bad submits early and tell the user clearly when one slips through. Server-side validation is SharePoint's "required column" setting (or Dataverse's table rules). Its job is data integrity, refuse a bad row no matter how the request arrived, the app, a flow, a bulk import, a direct API call. Use both. And the careful bit is that Power Apps formulas are not a security boundary. DisplayMode.Disabled and Visible = false help the user, they don't stop a determined actor from writing to the data source directly. The list (or Dataverse table) enforces who can write what.9. What you'll build
In the exercises you'll teach the form to refuse bad input, show error messages when something slips through, and control what's visible based on the user's role.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.