Pre-Flight Checks for Power Apps Forms: A Complete Validation Strategy

When a user clicks Submit on a form, you don't want ill-formatted or incomplete data to travel all the way to your SharePoint list. By adding a custom validation layer in Power Apps, you can check each field against your business rules before the form is ever saved. This tutorial will guide you through building such a layer for a sample Project Registration app – and you can apply the same pattern to any Power Apps form.

Scenario: Project Registration Form

A consulting firm needs its project managers to submit new project requests through a Power Apps form. The firm's governance rules are:

• Requester Name – mandatory, cannot be blank.
• Team Size – must be a number greater than zero.
• Start Date – must be a future date and no more than 90 days from today.
• Contact Phone – must follow the US format ###-###-####.
• Contact Email – must look like a valid email address.

These rules are evaluated when the user presses the Submit button. If any rule fails, the corresponding field gets a red border and a descriptive error message appears beneath it.

Setting Up the SharePoint List

Create a new SharePoint list named Project Registrations with the following columns:

Leave the list empty; the form will populate it.

Creating the Power Apps Form

1. Go to make.powerapps.com and create a new blank app.

2. Connect it to the Project Registrations SharePoint list.

3. Insert a modern form control (classic also works) and set its Items property to the list name:

   powerfxForm Items

   Copy

   'Project Registrations'

4. Arrange the fields in the order you prefer. Rename the default text input and date picker controls to something descriptive (e.g., txtRequesterName, txtTeamSize, dpStartDate, txtPhone, txtEmail). This will make your formulas much easier to read.

5. Set the form's FormMode property to FormMode.New so that it always creates a new record.

The Validation Trick: Context Variables

We store the validation result for each field in a context variable. A master variable varSubmitted indicates that the form has been attempted. All variables are updated inside the Submit button's OnSelect property.

Add a Submit button below the form and paste this code into its OnSelect:

UpdateContext({varSubmitted: true});
UpdateContext({varNameValid: !IsBlank(txtRequesterName.Value)});
UpdateContext({varTeamSizeValid: Value(txtTeamSize.Value) > 0});
UpdateContext({varDateValid: dpStartDate.SelectedDate > Today() && (dpStartDate.SelectedDate - Today() <= 90)});
UpdateContext({varPhoneValid: IsMatch(txtPhone.Value, Match.Digit & Match.Digit & Match.Digit & "-" & Match.Digit & Match.Digit & Match.Digit & "-" & Match.Digit & Match.Digit & Match.Digit & Match.Digit)});
UpdateContext({varEmailValid: IsMatch(txtEmail.Value, Match.Email)});

If(
  varNameValid && varTeamSizeValid && varDateValid && varPhoneValid && varEmailValid,
  SubmitForm(FrmProjectRegistration),
  Notify("Please fix the highlighted errors.", NotificationType.Error)
)

Wiring Up the ValidationState Property

Each text input or date picker has a ValidationState property that accepts "Error" or "None". When set to "Error", the control shows a red border. We set this property based on our variables and the varSubmitted flag.

For RequesterName (the text input inside the field card):

If(varSubmitted && !varNameValid, "Error", "None")

For TeamSize:

If(varSubmitted && !varTeamSizeValid, "Error", "None")

For StartDate (the date picker control):

If(varSubmitted && !varDateValid, "Error", "None")

For ContactPhone:

If(varSubmitted && !varPhoneValid, "Error", "None")

For ContactEmail:

If(varSubmitted && !varEmailValid, "Error", "None")

Displaying Error Messages

Insert a Label control beneath each form field. Set its Text property (or Value for classic labels) to show the appropriate message only when the field is in an error state. Change the label's FontColor to Color.Red.

Requester Name error label:

If(txtRequesterName.ValidationState = "Error", "Requester name is required.")

Team Size error label:

If(txtTeamSize.ValidationState = "Error", "Team size must be greater than zero.")

Start Date error label (two possible messages depending on which rule fails):

If(
  dpStartDate.ValidationState = "Error",
  If(
      dpStartDate.SelectedDate <= Today(),
      "Start date must be a future date.",
      "Start date must be within the next 90 days."
  ),
  ""
)

ContactPhone error label:

If(txtPhone.ValidationState = "Error", "Phone must be in the format ###-###-####.")

ContactEmail error label:

If(txtEmail.ValidationState = "Error", "Enter a valid email address.")

Performance & Security Notes

• All validation runs client‑side – no data travels to the server until you call SubmitForm. This keeps the experience responsive and reduces network overhead.
• The context variables we create are local to the user's session; they don't affect other users or require exclusive data source locks.
• Form validation in Power Apps is a convenience layer, not a security boundary. Always enforce your validation rules again on the data source (e.g., using SharePoint column validation, Power Automate flows, or business rules for Dataverse).

Common Mistakes & Troubleshooting

• ValidationState never turns red – Did you set varSubmitted to true on the button? Without that flag, the If conditions always fall to "None".
• All fields show error immediately after the first click – That’s by design: once varSubmitted is true, every non‑valid field will show an error. Users must correct all errors before resubmitting. You can add a Reset button that sets varSubmitted = false if needed.
• Error messages appear on first load – Use a conditional formula that only shows the message when the corresponding ValidationState equals "Error".
• Submit still saves despite errors – Double‑check the If condition that wraps SubmitForm. A typo or missing variable can cause the whole expression to evaluate incorrectly.
• Modern date picker border – Some modern date pickers in Power Apps don't display a red border when ValidationState is "Error". The error message label is your fallback, so it must be present and positioned correctly.

Final Recommendation

Client‑side validation improves the user experience and keeps dirty data out of your data sources. While Power Apps offers built‑in form validation (the Valid property and the header message), the approach shown here gives you full control over each field's error state and messaging.

Start simply: implement one or two rules, test thoroughly, then add more. Avoid over‑complicating the formula – many small UpdateContext lines are easier to debug than a single, monstrous If statement.

References

• Original article by Matthew Devaney: How To Validate A Power Apps Form Before Submission
• Microsoft Power Fx documentation: IsMatch function
• Microsoft Power Apps documentation: Form validation (placeholder – verify the exact URL)