Today, Notion doesn’t allow validation of field unicity. For example, using a form where I’m asking users to input their name and email, a user will be able to submit multiple time the same email (multiple rows in the database will contain the same email) which I would like to avoid as this email field is used to identify the user when he login to the app.
I saw people asking about this feature on Reddit for example without finding a solution. I guess that should not be too difficult to tackle for notionapps and that will 1/ ensure the quality of data and 2/ potentially bring new users looking for such a solution.
Thank you for the feature request, Julien. We have noted this feature in our internal roadmap, but do not have a date for it yet. I will update here once we decide to work on it.
This request is on the roadmap. Status: not started. It is next in the queue.
Vote on this thread to tell us whether we should re-prioritize it. We pay attention to the votes.
Problem
Notion will store the same value twice. On a form, a person can submit an email that is already in the database. When that email is how the app recognizes the person at login, the duplicate breaks the match.
Who it is for
Makers who need one row per email, or per any other property that must stay unique, including signup.
What happens today
Submit creates the row even when another row already has the same value. A check made in an automation can lose a race if two people submit together.
Requirement
The maker chooses which properties must be unique.
On submit, if another row already has that value, the form is rejected. The person sees a clear message that says the value is already used. The duplicate row is not created. A different value still submits. The check holds when two people submit the same value at the same time.
Out of scope
This does not change Notion’s own rules for the database. It does not merge two existing duplicates. It does not make every property unique unless the maker selected it.
Success criteria
A second signup with an email that is already stored is rejected, and no new row is created.
The person sees a message that the email is already used.
A new email still creates the row.
Two submits of the same email at the same time leave one row.
A property the maker did not mark unique can still repeat.