
Picture this: your team has been using a Power Apps form to log customer service tickets for three months. The data flows into a SharePoint list, gets pulled into a Power BI dashboard, and drives weekly reports for senior leadership. Then someone opens the form on a Monday morning, types "N/A" into the phone number field, leaves the email blank, and submits. Now your automated follow-up email workflow fails, your dashboard shows a blank customer record, and someone has to manually hunt down the correct information. All of this — entirely preventable.
Bad data doesn't just cause inconvenience. In business applications, it breaks downstream processes, erodes trust in your systems, and costs real time to clean up. The solution isn't to trust that users will do the right thing. The solution is to build forms that make it structurally difficult to submit bad data in the first place. That's exactly what data validation does, and Power Apps gives you powerful, flexible tools to implement it right inside your formulas.
By the end of this lesson, you'll know how to use three of Power Apps' most important validation functions — If, IsBlank, and IsMatch — to catch bad input before it ever reaches your data source. You'll validate required fields, check for properly formatted email addresses and phone numbers, and give users clear, helpful error messages that guide them toward correct submissions.
What you'll learn:
If function works in Power Apps and why it's the foundation of all conditional logicIsBlank to detect empty required fields and prevent incomplete submissionsIsMatch with regular expressions to validate data formats like emails and phone numbersBefore diving in, you should have:
You do not need any coding background. Every formula concept will be explained from scratch.
When you build a form in Power Apps, you're working in a tool called Power Apps Studio, a visual editor where you drag and drop controls onto a canvas. Every control — a text box, a button, a label — has a set of properties that define how it looks and behaves. You set those properties using formulas typed into the formula bar at the top of the screen.
This is fundamentally different from traditional programming. Instead of writing a procedure that runs when something happens, you write formulas that describe what a property is at any given moment. Think of it like a spreadsheet: in Excel, a cell's value is defined by a formula that recalculates whenever something changes. Power Apps works the same way — your formulas are always live, always recalculating.
This matters for validation because it means you can tie the behavior of your Submit button directly to whether the form data is valid — no event handlers, no imperative code, just a formula that says "this button is disabled when the form is incomplete." The button doesn't become clickable because you called a function; it becomes clickable because the formula describing its DisplayMode property evaluates to Edit rather than Disabled.
Keep this mental model in mind. It will make the formulas we write feel intuitive rather than arbitrary.
If is the most fundamental logic function in Power Apps. It evaluates a condition and returns one of two (or more) results depending on whether that condition is true or false.
The basic syntax looks like this:
If(condition, result_if_true, result_if_false)
Let's say you have a text input called TextInput_Email and you want to display a message based on whether it has any content. You could write:
If(TextInput_Email.Text = "", "Email is missing", "Email looks good")
In plain English: "If the email input's text is an empty string, say 'Email is missing'; otherwise say 'Email looks good.'"
If can also be nested — you can chain multiple conditions:
If(
TextInput_Email.Text = "",
"Email is required",
TextInput_Name.Text = "",
"Name is required",
"All good — ready to submit"
)
Power Apps reads this left to right: check the first condition, and if it's true, return the first result. If not, check the second condition, and so on. The final argument with no paired condition is the fallback — the "else."
Tip: You'll see
Ifused everywhere in Power Apps — to change colors, show or hide controls, enable or disable buttons, and display error messages. Mastering it unlocks a huge portion of what the platform can do.
IsBlank answers one question: is this value empty? It returns true if the value is blank (empty string, null, or not yet filled in) and false if it contains anything at all.
IsBlank(TextInput_Name.Text)
This returns true if the Name field is empty, false if it has any content.
On its own, IsBlank is just a detector. The real power comes when you combine it with If to take action based on the result.
Here's a common pattern: you add a Label control below a text input, and you use its Text property to show an error message only when the field is empty.
Select your label, click into the Text property in the formula bar, and enter:
If(IsBlank(TextInput_Name.Text), "⚠ Name is required", "")
When the field is empty, the label displays the warning. When the user types something, the label goes blank. Clean, immediate feedback — no submit required.
You can take this further by also changing the label's Color property to make the error visually obvious:
If(IsBlank(TextInput_Name.Text), RGBA(200, 0, 0, 1), RGBA(0, 0, 0, 0))
That formula shows the label in red when the field is blank, and makes it fully transparent (invisible) when the field has content.
Alternatively, you can control the label's Visible property instead of its Text:
IsBlank(TextInput_Name.Text)
When this returns true, the label is visible. When it returns false, it disappears entirely. This approach is slightly cleaner visually, and it's worth knowing both techniques.
Warning: Don't confuse
IsBlankwith checking for a space. If a user types a single space into a text field,IsBlankwill returnfalsebecause the field technically has content. If you want to catch that edge case, useIsBlank(Trim(TextInput_Name.Text)). TheTrimfunction strips leading and trailing whitespace before the check.
IsBlank tells you if something is there. IsMatch tells you what kind of thing it is. This is the function you use when "any text" isn't good enough — when the data needs to follow a specific format.
IsMatch checks a text value against a pattern and returns true if the value matches that pattern, or false if it doesn't. The patterns it uses are called regular expressions (often abbreviated as "regex"), which are strings of characters that describe a text pattern.
The syntax is:
IsMatch(text_to_check, pattern)
Power Apps ships with several pre-built patterns so you don't have to write regex from scratch. These are available via the Match enum:
| Pattern | What it matches |
|---|---|
Match.Email |
Standard email addresses |
Match.Digits |
Strings of only numeric digits |
Match.Letter |
Strings of only letters |
Match.MultipleLetters |
One or more consecutive letters |
Match.MultipleDigits |
One or more consecutive digits |
To validate an email address using the built-in pattern:
IsMatch(TextInput_Email.Text, Match.Email)
This returns true for inputs like sarah.jones@contoso.com and false for inputs like sarah.jones or not-an-email.
Now combine it with If to build an error message:
If(
IsBlank(TextInput_Email.Text),
"⚠ Email is required",
Not(IsMatch(TextInput_Email.Text, Match.Email)),
"⚠ Please enter a valid email address",
""
)
Read that formula carefully. First check: is the field blank? If yes, say it's required. Second check: does the content fail the email format test? (Not flips true to false and vice versa, so Not(IsMatch(...)) means "the match failed.") If yes, say the format is wrong. If both checks pass, return an empty string — no error.
This layered approach gives users specific, actionable feedback depending on their exact mistake.
Sometimes the built-in patterns aren't specific enough. Suppose you want to validate a US phone number that must follow the format (555) 867-5309. The built-in Match.Digits won't cut it because it doesn't account for parentheses, spaces, or dashes.
Here's a regex pattern for that exact format:
IsMatch(TextInput_Phone.Text, "\(\d{3}\) \d{3}-\d{4}")
Let's break down what this regex means, piece by piece:
\( — a literal opening parenthesis (the backslash "escapes" it because parentheses have special meaning in regex)\d{3} — exactly three digits (0–9)\) — a literal closing parenthesis — a literal space\d{3} — exactly three more digits- — a literal hyphen\d{4} — exactly four digitsSo the pattern \(\d{3}\) \d{3}-\d{4} matches (206) 555-1234 but rejects 2065551234, 206-555-1234, and (206)555-1234.
Tip: You don't need to be a regex expert to use Power Apps validation. For common patterns — ZIP codes, phone numbers, dates — you can find well-tested regex strings by searching something like "US ZIP code regex" online, then paste them directly into your
IsMatchformula. Test them carefully before deploying, but you don't need to write them from memory.
Individual error messages are great. But the gold standard of form validation is a Submit button that simply won't work until the form is valid. This is better UX because it makes the requirement unmistakably clear: you can't move forward until everything is in order.
In Power Apps, you control a button's interactivity through its DisplayMode property. Setting this to DisplayMode.Disabled grays out the button and prevents clicks. Setting it to DisplayMode.Edit makes it fully interactive.
Here's the pattern. Create a form with three fields: Name, Email, and Phone. Then select your Submit button and set its DisplayMode property to:
If(
IsBlank(TextInput_Name.Text) Or
IsBlank(TextInput_Email.Text) Or
Not(IsMatch(TextInput_Email.Text, Match.Email)) Or
IsBlank(TextInput_Phone.Text) Or
Not(IsMatch(TextInput_Phone.Text, "\(\d{3}\) \d{3}-\d{4}")),
DisplayMode.Disabled,
DisplayMode.Edit
)
Read this as: "If any of these conditions are true — any required field is blank, the email format is wrong, or the phone format is wrong — disable the button. Otherwise, enable it."
The Or keyword means the whole condition is true if at least one of those sub-conditions is true. The button stays disabled until every single one of those sub-conditions is false.
Warning: Be careful not to make your validation so strict that it's frustrating. If you require phone numbers in the format
(555) 867-5309but your users are pasting numbers from a CRM that formats them as555-867-5309, your form will feel broken to them. Choose your format requirements intentionally, communicate them clearly in placeholder text, and consider whether you can useTrimor other cleanup functions to accept reasonable variations.
Let's walk through building a simple customer service intake form from start to finish.
Step 1: Set up your controls
Add three Text Input controls and label them clearly in their HintText property:
TextInput_Name — HintText: "Full Name"TextInput_Email — HintText: "Email (e.g., you@company.com)"TextInput_Phone — HintText: "Phone (e.g., (206) 555-1234)"Add three Label controls positioned below each input — these will be your error messages.
Add a Button control at the bottom — this is your Submit button.
Step 2: Set error message formulas
For Label_NameError, set the Text property to:
If(IsBlank(TextInput_Name.Text), "⚠ Full name is required", "")
For Label_EmailError, set the Text property to:
If(
IsBlank(TextInput_Email.Text),
"⚠ Email is required",
Not(IsMatch(TextInput_Email.Text, Match.Email)),
"⚠ Please enter a valid email address (e.g., you@company.com)",
""
)
For Label_PhoneError, set the Text property to:
If(
IsBlank(TextInput_Phone.Text),
"⚠ Phone number is required",
Not(IsMatch(TextInput_Phone.Text, "\(\d{3}\) \d{3}-\d{4}")),
"⚠ Use format: (555) 867-5309",
""
)
Step 3: Set error label colors
For each error label, set the Color property to RGBA(200, 0, 0, 1) so the messages appear in red.
Step 4: Disable the Submit button
Select your Submit button and set its DisplayMode property to the compound formula from the previous section.
Step 5: Test it
Press the Play button (triangle icon in the top right of Power Apps Studio) to enter preview mode. Try submitting with blank fields. Try entering a malformed email. Try entering a phone number without parentheses. Watch the error messages appear and the button stay disabled. Then fill in all three fields correctly and watch the button become active.
Build a volunteer registration form with the following fields and validation requirements:
Match.Letter won't work for multiple letters, so use Match.MultipleLetters)"\d{5}")For each field, create an error label that shows an appropriate message when validation fails. Wire a Submit button so it's only enabled when all four fields pass their validation checks.
Stretch goal: Add a Dropdown control for selecting a volunteer role (options: "Event Setup", "Registration Desk", "Cleanup Crew"). Add validation that ensures the user has made a selection before enabling Submit. Hint: for a Dropdown, check Dropdown_Role.SelectedText.Value — it will be empty string if nothing is selected.
"My IsMatch formula always returns false, even for valid input."
Check your regex for escaping. In Power Apps, you write regex inside a quoted string, which means some characters need careful handling. Parentheses in regex are \( and \). If you're copying a regex from an online tool, test it carefully in Power Apps — behavior can occasionally differ.
"The error message shows even when I haven't touched the field yet."
This is a UX problem, not a technical one. You might want to only show errors after the user has interacted with the field. One way to handle this is to set a variable when the user leaves the field. Select the text input, go to its OnChange or OnSelect property, and set UpdateContext({NameTouched: true}). Then wrap your error label formula in an additional If(NameTouched, [your validation formula], "").
"IsBlank is returning false even though the field looks empty."
The user may have typed a space. Wrap the value in Trim(): IsBlank(Trim(TextInput_Name.Text)).
"My Submit button is enabled but one field is still wrong."
Double-check your Or conditions. A missing Or between two conditions means they're being treated as separate arguments to If, not as a combined condition. Use the formula bar's autocomplete and error indicators to spot issues.
"The Match.Email pattern accepts addresses I don't want."
The built-in Match.Email pattern is fairly permissive. If you need stricter email validation — for example, requiring a specific domain — you'll need to write a custom regex. A pattern like "[a-zA-Z0-9._%+\-]+@contoso\.com" would restrict submissions to contoso.com addresses only.
You've just built the foundation of trustworthy form design. Here's what you now know how to do:
If to branch between results based on a condition — the core of all conditional logic in Power AppsIsBlank to detect empty required fields and display targeted error messagesIsMatch with both built-in patterns (Match.Email) and custom regex to validate data formatsDisplayMode property to your validation logic so the button only activates when all data is cleanThese three functions — If, IsBlank, and IsMatch — will appear in almost every serious Power Apps project you build. They're not validation-specific; they're general-purpose tools that happen to be perfect for this problem.
Where to go from here:
SubmitForm and Errors to handle server-side validation errors from your data source (SharePoint, Dataverse, SQL)UpdateContext and Set to manage state — like tracking which fields the user has touched — for more sophisticated UXPatch to write validated data directly to a data source with full control over exactly what gets savedGreat data starts at the point of entry. You're now equipped to defend that entry point.
Learning Path: Canvas Apps 101