HubSpot Form Data Validation Guide

I start HubSpot form validation with 3 checks: field types, property rules, and the submission path. Set required fields and supported format rules first, then test what reaches the CRM - not just what the form accepts.

In this guide, I cover how to:

• Set rules for email, phone, text, number, date, and choice fields.
• Add regex checks for fixed formats and conditional fields for follow-up questions.
• Test valid, invalid, blank, and boundary inputs on the live page.
• Separate field errors from spam rejections.
• Check Forms API requests and external form mappings, then confirm stored values and workflow results.

<u>Conditional logic controls what appears; it doesn’t validate relationships between fields.</u> And an accepted submission isn’t proof that every value was stored correctly. Before publishing, I check both the form experience and the CRM result, then assign owners for rule changes, sync errors, and spam reviews.

How to Set validation rules for HubSpot property

sbb-itb-5f36581

Step 1: Set Up Property Rules and Form Fields

Before building the form, define each field’s CRM property, whether it’s required, and how it will be validated. Use format rules for stored data, and apply routing logic only after the field passes validation. At submission, require only the information you need. Then add custom checks for edge cases and conditional fields for lead qualification.

Set CRM Property Rules

Go to Settings → Properties, open the property, and select the Rules tab. Before publishing, check that your subscription, property type, and submission source support the rule. Also, make sure the property is enabled for forms before adding it to the editor.

Existing values won’t be reformatted automatically. Check where each rule applies: property validation works differently across HubSpot entry points. Apply the rule where HubSpot validates submitted values - not just where it stores the property. Test valid, invalid, blank, and boundary values before publishing.

Set Up Email, Phone, and Choice Fields

Use HubSpot’s default Email field to create or update contacts and run its documented email checks. These check the format, domain and TLD validity, DNS MX or A records, and blocklist status. They don’t confirm mailbox ownership or guarantee deliverability. Allow or block specific domains only when needed, and explain the restriction clearly.

For phone fields, set the correct country behavior and test both national and international input. The default phone field has a country selector that you can’t hide in the form editor.

For choice fields, define a fixed set of labels and stored values before publishing. Use radio buttons for a few mutually exclusive choices, dropdowns for longer lists, and checkboxes only for multi-select. Add Not sure or Other if forcing a choice would skew the data. Don’t change labels or stored values after launch; integrations and reports may depend on them.

Match each validation rule to the right input using the table below.

Step 2: Add Custom Validation and Conditional Fields

Use custom checks only when HubSpot’s native field rules can’t meet the requirement. Apply property rules first, then add custom checks for unsupported formats and field dependencies. Keep restrictions narrow: regex works better for a fixed account-code format than for rejecting anything that looks unusual.

Validate Text With Regular Expressions

Add a regex rule where supported, paired with a specific error message. HubSpot documents RE2 syntax for supported text and textarea properties. Tell users what format you expect instead of showing a generic error.

For an account code that requires exactly two uppercase letters followed by four digits, use ^[A-Z]{2}[0-9]{4}$.

Test valid, blank, whitespace-padded, malformed, long, and pasted values. Check blank input separately: regex controls the format, while required-field rules determine whether a value must exist.

In the preview or published form, check the error message and behavior on desktop and mobile. Also confirm whether the value changes or gets rejected before reaching the CRM.

Use conditional logic only when another answer determines whether a field should appear or become required.

Show and Require Fields Based on Answers

Hypothetical business-inquiry setup: In the form’s logic controls, select Inquiry type as the triggering field, choose is any of, and match Multi-location rollout. Show Number of locations, then make it required where the editor supports that combination. Test that leaving it blank blocks submission. Switch to General question and confirm the field hides and no longer blocks submission. Save or activate the rule after testing. In legacy dependent-field setups, the dependent field must already exist before you can select it.

Conditional logic controls the form experience, not relationships between fields. For checks such as requiring a contract end date to fall after its start date, HubSpot directs teams to work with a developer on a custom form integrated through the Forms API. Validate data on the server before sending it to HubSpot, and return field-specific errors.

Then test for both visible errors and hidden submission failures.

Step 3: Test Submissions and Troubleshoot Errors

Test for both visible errors and submissions that fail without a warning. Use dedicated test contacts and email addresses, and send notifications to internal recipients while testing.

Try one valid submission, every invalid and boundary case, and each conditional path. Record whether each submission is accepted, rejected, or marked as spam, then check the CRM records and automation results. Repeat these tests on the live page, where scripts and consent settings may change how the form works.

Review Validation Errors and Spam Submissions

Separate validation failures from spam filtering before changing field rules. Go to Marketing > Forms and open the form to review regular submissions. If available, select the Spam tab to review blocked submissions.

Check the spam type before adjusting validation. Gibberish detection applies to Marketing Hub or Content Hub Professional and Enterprise plans. Release confirmed false positives promptly: spam submissions that aren't released may be automatically deleted after 90 days.

If the form passes checks in the editor but fails when submitted, check the request path next.

Check Forms API Limits and Validation Rules

Review the current documentation for the exact endpoint you're using. Check its authentication, payload structure, required fields, property names, accepted values, consent rules, response codes, and error format. Forms API submissions allow up to 1,000 field name/value pairs per request. That limit does not apply to every HubSpot endpoint.

A form can look valid in the editor and still fail API checks. Test invalid options, missing values, incorrect mappings, and rejected responses. Log timestamps, status codes, response bodies, and retries. Retry only temporary failures, using bounded backoff and controls to prevent duplicate submissions.

Test each data-entry path separately. Forms, CRM edits, imports, workflows, chatflows, and APIs may apply different checks. After an API request is accepted, inspect the destination record and automation history. An accepted request doesn't guarantee that every value was stored correctly or every workflow ran as expected.

Validate External Forms Before Sending Data to HubSpot

If another form builder sends data to HubSpot, test that source separately. For Reform, check field mappings, required values, and how its validation differs from HubSpot's checks.

Test whether partial multi-step submissions sync before the form is complete. Also, make sure reform.app is added to HubSpot's analytics tracking site-domain list.

Passing the builder's validation doesn't mean a submission will pass HubSpot's required-property, option-value, permission, spam, or API checks. Review integration errors and confirm that records are stored correctly before routing submissions to production.

Conclusion: Check Validation Before Publishing

After testing submissions, lock the final rule set before publishing. Check every property mapping, required field, validation rule, and conditional requirement. Save a release test log that includes pass/fail inputs, the form version, and the test date.

To keep rules stable after launch, assign owners for rule changes, sync errors, and spam reviews - including false positives. Keep a change log for every restriction.

Once the form is live, track lead quality - not just conversion rate. Compare field-level errors and abandonment with sales-accepted leads and booked meetings. If a field causes frequent errors without improving qualification, clarify its instructions before adding more restrictions.

FAQs

How can I update validation rules without breaking integrations?

Use a backend server or middleware layer to keep form logic separate from HubSpot properties. Route submissions through this layer to log them, check business rules, and transform data before sending it to the API.

Map fields with stable IDs - not labels or field positions - and make sure each property’s type matches the form value. Before deployment, test changes with a dedicated test email address and review every mapping, including hidden fields.

How can I prevent duplicate contacts from repeat submissions?

HubSpot matches contacts by email address. When someone submits a form using an email already on file, HubSpot typically updates the existing contact instead of creating a duplicate.

For API integrations, use POST /crm/v3/objects/contacts/batch/upsert and set idProperty to email. When retrying failed requests, use an idempotency key if your integration supports it to avoid duplicates after partial success.

Test forms in an incognito browser to keep existing browser cookies from affecting how HubSpot associates submissions with contacts. Incognito mode doesn’t override email matching: submitting an existing email can still update that contact.

How do I balance strict validation with form conversions?

Check required fields, formats, and lengths instantly on the client side. Run deeper API checks, such as email deliverability or lead enrichment, when users leave a field or step, not while they’re typing.

Let users continue if non-critical enrichment checks time out. Block progress only for clear, high-risk errors, such as invalid email syntax. Show clear error messages next to the relevant fields, and keep everything users have already entered.

Related Blog Posts

• Inline Validation: Best Practices for Forms
• 5 Data Validation Tips for Better Lead Quality
• How HubSpot Form Sync Works with CRMs
• Best Practices for CRM Email Form Automation