Preventing duplicate submissions

FormGrid can reject a submission when its value matches one that’s already been recorded. Turn on No duplicates on a field, and any later submission that reuses that value gets turned away.

Where you can use it

The setting is available on:

Turning it on

Click the drag handle on the left side of the field to open its settings.
Toggle No duplicates on.

From this moment on, FormGrid starts tracking new submissions against each other.

How matching works

FormGrid compares values after normalizing them, so small differences in formatting don’t sneak past the check.

Email is case-insensitive. Jane@example.com and jane@example.com count as the same address. Leading and trailing whitespace is ignored.
Short text and Hidden field are case-sensitive. Jane and jane are treated as different. Leading and trailing whitespace is ignored.
Phone number is compared in its E.164 form, so 176 12345678 and +4917612345678 for a German mobile both resolve to the same value.

Empty answers are never counted as duplicates. If a respondent leaves an optional unique field blank, the next person can leave it blank too.

What respondents see

When someone submits a value that’s already on file, FormGrid replaces the form with a page titled “Already received.” showing the message “Duplicate responses aren’t allowed for this form.”

The page doesn’t reveal which value collided, so a respondent can’t tell from the message whether their email, phone number, or hidden value was the one already in the list.

Turning it on for a form that already has responses

Existing responses are grandfathered in. FormGrid doesn’t go back and check them, and it doesn’t block new submissions for values that already appeared in older responses. The check only starts comparing submissions from the moment you flip the toggle.

If you want the rule to apply to the full history, delete the older responses, or export them and start fresh, before turning No duplicates on.

Inside a Repeat

If a unique field lives inside a Repeat, all of its rows share one duplicate check. Say you have a “guest email” field that repeats for each guest. Once a response uses alice@example.com for any guest, no later response can use that email for any of its guests.

The check only kicks in across separate responses. Within a single response, the same value in two rows is fine.

With Conditions

If a Condition hides a unique field for a particular respondent, that submission isn’t tracked for that field. The uniqueness check only runs when the field was actually answered.

Deleting a response frees the value

Deleting a response from the response table releases the unique values it held. The next respondent can submit those same values again.

In webhook payloads

Each field’s config.unique in the webhook payload reflects whether No duplicates is on for that field. Use this on the receiving end when you want to know which fields are duplicate-protected.

Tips

Use it on Email for sign-ups, RSVPs, or anything else where you want one entry per email address. The case-insensitive match catches Jane@ and jane@ as the same person.
Pair it with a Hidden field carrying a user ID or invite code when you want one submission per logged-in user, or one-time code redemption.
“Duplicate” means the same value, not the same person. Two different people who happen to share an email address will collide on the second submission.