Wicked Smart Data
LearnArticlesAbout
Sign InSign Up
LearnArticlesAboutContact
Sign InSign Up
Wicked Smart Data

The go-to platform for professionals who want to master data, automation, and AI — from Excel fundamentals to cutting-edge machine learning.

Platform

  • Learning Paths
  • Articles
  • About
  • Contact

Connect

  • Contact Us
  • RSS Feed

© 2026 Wicked Smart Data. All rights reserved.

Privacy PolicyTerms of Service
All Articles
Power Apps Data Validation: Using If, IsBlank, and IsMatch to Prevent Bad Data in Forms

Power Apps Data Validation: Using If, IsBlank, and IsMatch to Prevent Bad Data in Forms

Power Apps🌱 Foundation15 min readJul 15, 2026Updated Jul 15, 2026
Table of Contents
  • Introduction
  • Prerequisites
  • Understanding Why Validation Lives in the Formula Bar
  • The If Function: Power Apps' Decision Engine
  • IsBlank: The Simple Required Field Check
  • Displaying an Error Message for a Blank Field
  • Making the Label Itself Disappear
  • IsMatch: Validating Data Formats with Patterns
  • Using Built-In Match Patterns
  • Writing Your Own Regex Patterns
  • Wiring It All Together: Disabling the Submit Button
  • Putting It All Together: A Complete Example

Power Apps Data Validation: Using If, IsBlank, and IsMatch to Prevent Bad Data in Forms

Introduction

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:

  • How the If function works in Power Apps and why it's the foundation of all conditional logic
  • How to use IsBlank to detect empty required fields and prevent incomplete submissions
  • How to use IsMatch with regular expressions to validate data formats like emails and phone numbers
  • How to display dynamic error messages that appear only when input is invalid
  • How to wire everything together to disable a Submit button until the form is clean

Prerequisites

Before diving in, you should have:

  • A Power Apps account (free developer plan works fine)
  • Basic familiarity with the Power Apps Studio interface — you should know how to add a screen, insert a text input control, and insert a button
  • A rough understanding that Power Apps formulas live in a property panel on the right side of the screen

You do not need any coding background. Every formula concept will be explained from scratch.


Understanding Why Validation Lives in the Formula Bar

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.


The If Function: Power Apps' Decision Engine

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 If used 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: The Simple Required Field Check

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.

Displaying an Error Message for a Blank Field

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.

Making the Label Itself Disappear

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 IsBlank with checking for a space. If a user types a single space into a text field, IsBlank will return false because the field technically has content. If you want to catch that edge case, use IsBlank(Trim(TextInput_Name.Text)). The Trim function strips leading and trailing whitespace before the check.


IsMatch: Validating Data Formats with Patterns

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)

Using Built-In Match Patterns

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.

Writing Your Own Regex Patterns

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 digits

So 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 IsMatch formula. Test them carefully before deploying, but you don't need to write them from memory.


Wiring It All Together: Disabling the Submit Button

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-5309 but your users are pasting numbers from a CRM that formats them as 555-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 use Trim or other cleanup functions to accept reasonable variations.


Putting It All Together: A Complete Example

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.


Hands-On Exercise

Build a volunteer registration form with the following fields and validation requirements:

  1. First Name (required, letters only — use Match.Letter won't work for multiple letters, so use Match.MultipleLetters)
  2. Last Name (required)
  3. Email (required, must be a valid email format)
  4. ZIP Code (required, must be exactly 5 digits — regex: "\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.


Common Mistakes & Troubleshooting

"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.


Summary & Next Steps

You've just built the foundation of trustworthy form design. Here's what you now know how to do:

  • Use If to branch between results based on a condition — the core of all conditional logic in Power Apps
  • Use IsBlank to detect empty required fields and display targeted error messages
  • Use IsMatch with both built-in patterns (Match.Email) and custom regex to validate data formats
  • Combine these functions to build multi-condition validation that provides specific, actionable feedback
  • Wire a Submit button's DisplayMode property to your validation logic so the button only activates when all data is clean

These 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:

  • Error handling on submit: Learn how to use SubmitForm and Errors to handle server-side validation errors from your data source (SharePoint, Dataverse, SQL)
  • Form controls vs. standalone inputs: Explore how Power Apps' built-in Form control handles some validation automatically when connected to Dataverse with required column settings
  • Variables and collections: Deepen your understanding of UpdateContext and Set to manage state — like tracking which fields the user has touched — for more sophisticated UX
  • Patch function: Once your validation is solid, learn how to use Patch to write validated data directly to a data source with full control over exactly what gets saved

Great data starts at the point of entry. You're now equipped to defend that entry point.

Learning Path: Canvas Apps 101

Previous

Canvas App State Management at Scale: Global Variables, Named Formulas, and Context Isolation for Enterprise Apps

Next

Canvas App Error Handling: Building Resilient Apps with IfError, Notify, and Graceful Failure Patterns*

Related Articles

Power Apps⚡ Practitioner

Configuring Power Apps Connectors with On-Premises Data Gateway: Connecting Canvas Apps to SQL Server and Local Systems

22 min
Power Apps🌱 Foundation

Power Apps Media Controls: Capturing Photos, Scanning Barcodes, and Uploading Files in Canvas Apps

16 min
Power Apps🔥 Expert

Canvas App Embedding in Microsoft Teams: Configuring Personal Apps, Tab Apps, and Permission Scopes for Enterprise Deployment

32 min

On this page

  • Introduction
  • Prerequisites
  • Understanding Why Validation Lives in the Formula Bar
  • The If Function: Power Apps' Decision Engine
  • IsBlank: The Simple Required Field Check
  • Displaying an Error Message for a Blank Field
  • Making the Label Itself Disappear
  • IsMatch: Validating Data Formats with Patterns
  • Using Built-In Match Patterns
  • Writing Your Own Regex Patterns
  • Hands-On Exercise
  • Common Mistakes & Troubleshooting
  • Summary & Next Steps
  • Wiring It All Together: Disabling the Submit Button
  • Putting It All Together: A Complete Example
  • Hands-On Exercise
  • Common Mistakes & Troubleshooting
  • Summary & Next Steps