Skip to content

Validate Email and Phone on Form Fields

This guide is for app makers building in the NotionApps builder.

It explains how to require a valid email or phone format on a text field — so end users get a clear error when they leave a bad value, and submit is blocked until it’s fixed.

If you only remember one sentence:

On a text field’s Behaviour settings, turn on Validate input, then choose Email or Phone.


Use this guide if you:

  • Build or edit apps in the builder
  • Have a Create Form or Update Form with a text (or long text) field
  • Want that field to accept only a valid email address or phone number

You do not need this guide for:

  • Making a field mandatory (that is still Is Required)
  • Choosing which Notion property the field writes to (that is the field’s Input Property)
  • Hiding a field for some users (that is Visibility Logic)

Without validation, a “Email” text field can accept anything — hello, not-an-email, or a real address. The app will still save it.

With Validate input turned on and type Email:

  • user@example.com → allowed
  • not-an-email → error when the user leaves the field, and submit stays blocked

Phone works the same way with type Phone.

Is Required and Validate input are independent:

Is Required Validate input Empty value Bad format (non-empty)
Off Off OK OK
On Off Error (required) OK
Off On OK Error (invalid email/phone)
On On Error (required) Error (invalid email/phone)

Empty values never fail format validation. If the field is optional, users can leave it blank even when Validate input is on.


When a value fails validation:

  • After they leave the field (blur), a field error appears under the input
  • Typical messages:
    • Email: Please enter a valid email address
    • Phone: Please enter a valid phone number
  • Submit / Next stays blocked until the value is fixed or cleared (if the field is not required)

Fixing the value and leaving the field again clears the format error.


  1. Open your app in the builder.
  2. Open a Form (Add Item) or Form (Update Item) that has a Text Box (or long text) field — for example a contact email or phone number field.
  3. Prefer a dedicated field (e.g. “Email”, “Phone”) rather than a general “Name” field, unless you truly want that field validated as email/phone.

  1. In the builder, go to Screens.
  2. Select the create or update form that contains the field (for example Add Contact or Add Restaurant).
  3. Keep the right-hand inspector open for that screen.

You should be editing a form, not a list or detail-only screen.


  1. On the form inspector, stay on the Content tab
    (field settings live here — not on the screen-level Behaviour tab, which is for submit button, success message, and similar form-wide options).
  2. In the field list on the right, click the text field row (for example Input Email or Input Phone).
  3. The field’s settings expand: label, helper text, and Behaviour options for that field.

In the field’s Behaviour section (below Is Required):

  1. Turn Validate input On.
  2. A Validation type dropdown appears.
  3. Choose:
    • Email — value must look like a normal email address
    • Phone — value must look like a real phone number: digits with optional +, spaces, dashes, parentheses, or dots; after ignoring those separators, 10–15 digits

Defaults when you first turn the switch on: type is Email.

Publish when you’re ready so end users get the new behavior.


Step 4 — Decide whether the field is also required

Section titled “Step 4 — Decide whether the field is also required”
Goal Settings
Optional email/phone; if filled, must be valid Is Required Off · Validate input On
Must enter a valid email/phone Is Required On · Validate input On
Must enter something, any text OK Is Required On · Validate input Off

Step 5 — Test in preview or the published app

Section titled “Step 5 — Test in preview or the published app”
  1. Open the form as an end user (preview or published app).
  2. Enter a bad value (e.g. not-an-email or 123) and tap outside the field → you should see the error.
  3. Enter a good value (e.g. user@example.com, 1234567890, or (555) 123-4567) and leave the field → the error clears.
  4. Try submit with a bad value still present → submit should stay blocked.
  5. With validation on and required off, clear the field → empty should be allowed.

Phone validation accepts common ways people type numbers. Separators are allowed for entry; the app checks that the digits form a plausible length. The value is saved as typed (not rewritten).

Allowed: digits, optional leading +, spaces, -, (, ), .
Digit count after stripping separators: 10–15

Example Result
1234567890 Valid
(555) 123-4567 Valid
555-123-4567 Valid
+1 555 123 4567 Valid
+44 7911 123456 Valid
555.123.4567 Valid
123 Invalid (too short)
555-CALL-NOW Invalid (letters)

Extensions (ext, x123), letters, and symbols other than the separators above are not accepted.


Email validation uses the same pattern as elsewhere in NotionApps (standard name@domain shape).

Example Result
user@example.com Valid
not-an-email Invalid
user@ Invalid

Mistake What happens Fix
Looking under the screen Behaviour tab You see submit button / success message, not field validation Stay on Content, select the field, use the field’s own Behaviour section
Turning on Validate input but never publishing Preview may show it; live users don’t Publish the app
Expecting empty optional fields to error Empty always passes format checks Turn Is Required On if blank should be blocked
Validating a “Name” field as Email Users can’t enter a normal name Use Email/Phone type only on fields meant for those formats
Letters or extensions in the phone field Value fails validation Use digits and standard separators only (+, spaces, dashes, parentheses, dots)

  • Form screen open in the builder
  • Content tab → text field selected
  • Validate input On
  • Validation type = Email or Phone
  • Is Required set for whether blank is allowed
  • Helper text mentions the expected format (optional but helpful)
  • Published and tested with a bad value, a good value, and (if optional) empty

Need Where
Field must not be empty Is Required on the same field
Barcode / QR into a text field Show Scanner on the same field
Prefill from a URL Default Value → URL param source
Hide the field for some users Visibility Logic on the field
Form-wide submit button / success message Screen Behaviour tab (not the field)

Annotated builder screenshot: Form fields (Logic)

Annotated builder screenshot: Form Behaviour

Validation is configured on the field inspector Behaviour for text / long text fields on Create or Update forms. Screen-level inventory: Form (Add Item) and Form (Update One Item).

What it does: Turns on format checking for the field.
How to use it: Enable on email/phone fields, then choose Email or Phone.
Why / recommended default: On for contact fields that must be well-formed; off for free-text notes.

What it does: Selects which format rules run on blur and submit.
How to use it: Match the Notion property purpose. Do not use Phone for OTP codes stored as text unless the format fits.
Why / recommended default: Email for email properties; Phone for phone properties.

What it does: Blocks empty values. Independent from Validate input.
How to use it: Combine with Validate input when the field must be present and correctly formatted.
Why / recommended default: Required + Email for primary contact email.