How do I map form fields to Notion database properties?

To map form fields to Notion properties, connect each form question to one property of a matching type, then make sure the answer arrives in the format Notion accepts. Text goes to text, dates go to date, choices go to select or multi-select. Skip read-only properties like formulas and rollups entirely.

How form-to-Notion mapping works

Every form that writes to Notion turns one submission into one database page, and each answer fills one property on that page. In Notion’s own forms, the forms help page says each question “is connected to a property in your database,” and the question type is the equivalent of the property type.

Third-party tools do the same thing through Notion’s API. They read your database’s properties, show them as fields, and let you pick which question fills each one. The rules come from Notion’s page property values reference, not from the form tool.

What you need before you map

Get the database right first, because mapping is easier to fix in Notion than in the form.

1. One database, shared with the form tool. A third-party tool can only see databases you’ve shared with its connection.
2. A property for every answer you want to filter or sort on. Long notes can live in a text property; anything you’ll group by deserves its own select.
3. Final property types. Changing a type after mapping can break writes until you remap.
4. Select options without commas. Notion’s API says option names “cannot contain commas.”

Which question type fits each Notion property

Each Notion property expects a specific value, and the form question should produce exactly that. This table comes from Notion’s API reference and request limits page.

Requests that go over a limit fail with a validation_error, so one overlong answer in a text field loses the whole row.

Properties a form can’t fill

Some properties are set by Notion and can never be mapped. The API reference marks created_time, created_by, last_edited_time and last_edited_by as read-only values that “Notion sets.” Formula and rollup results are read-only too, and for unique IDs, “Notion assigns the number.”

If your tool shows one of these as a mapping target, leave it blank. People often map a “Submitted on” question to Created time. Skip it: Notion fills Created time when the page is made.

Map form fields to Notion properties step by step

The mapping steps are the same in most tools: pick the database, match the title, then go property by property.

1. Pick the database the responses should land in.
2. Map the Name property first. Each database has exactly one, and it labels every row. Use the respondent’s name, a company, or a short subject line.
3. Match each question to a property of the same type, using the table above.
4. Check select options. Make the form’s choices match your Notion options exactly, or let the tool add new ones.
5. Leave read-only properties unmapped.
6. Submit a test response with long text, commas and every option ticked, then open the new page in Notion.

A worked example: a client intake form

A client intake form mapped to a Clients database:

• “Your name” → Name (title)
• “Work email” → Email
• “Budget” → Number, with the form question set to accept numbers only
• “Services needed” → Multi-select with options Design, Branding, Web
• “Start date” → Date
• “Project brief” → Text
• Stage → set by you later, not mapped to any question

The mistake I see most is mapping “Services needed” to a status property. Status can’t take more than one value, and a page write “does not create a new status option,” so any choice that isn’t already a status fails. A full template for this case is in the Notion client intake form guide.

Select, status and choice questions

Choice questions cause most mapping failures because the value has to match an option. For select and multi-select, Notion’s API reference says writes can use the option’s name or ID, and “a new option name adds an option to the schema” if the connection can write to the database.

The catch: a typo in the form creates a second option in Notion. “Web design” and “Web Design” end up as two tags. Status works the other way: it only accepts options you’ve already created.

My take: copy your Notion option names into the form, character for character, and never let respondents type a value that becomes a tag.

People, relation and file questions

People, relation and file properties don’t take plain text, so a regular text question can’t fill them. Person properties need Notion user IDs, and relation properties need page IDs from the related database. The API reference adds that you must “share the related database with your connection too.”

Both need a form tool that shows a picker built from your workspace. I cover each in the Notion form person property guide and the relation property guide.

Files work through file objects or external URLs. A file write “replaces the full list,” so tools add every file in one go. See Notion form file uploads for where files actually get stored.

Keeping mappings working after you edit the database

Renaming a property is safer than it looks, because Notion keeps the ID. The API reference says “a property’s id stays the same when its name changes,” so tools that map by ID keep working. Tools that map by name don’t, and you’ll need to refresh the database inside the tool.

In native Notion forms, renaming a question renames its property too by default. Notion’s help says you can toggle off Sync with property name if you want the question wording to differ.

Changing a property’s type is what breaks things. A text property turned into a select won’t accept the same answers, so remap that field and run a test response afterwards. If rows stop arriving entirely, use the checks in why a form is not syncing to Notion.

How tools differ on mapping

Most form tools ask you to map each field by hand. As of November 2026, Tally’s Notion help says you can only map one field to a Notion property, and its native integration doesn’t support Person or Relation yet.

nDBForms works the other way round. It reads your database’s properties and generates matching form fields, with 17 question types that map to Notion property types, including relation and people. File uploads go to the owner’s Google Drive, with the link written to Notion, on the Pro plan.

The limitation: automatic mapping only helps if your database is set up well. If a property has the wrong type, nDBForms builds the wrong question, so fix the database before you generate the form.

FAQ

Which Notion properties can’t a form fill?

Formula, rollup, Created time, Created by, Last edited time, Last edited by and unique ID values are set by Notion or read-only. Map form questions to regular properties instead.

What should I map to the Name (title) property?

Every Notion database has exactly one Name property, so map a short text answer that identifies the row, like the respondent’s name or company. Some tools also let you use a submission ID.

Will a form create new select options in Notion?

For select and multi-select, a new option name is added to the schema if the connection can write to the database. Status is different: a page write can’t create a new status option.

Does renaming a Notion property break the mapping?

A property’s ID stays the same when its name changes, so tools that map by ID keep working. Tools that map by name may need you to refresh the database and remap the field.

How do I map a person or relation question?

Person properties need Notion user IDs, and relation properties need the IDs of pages in the related database, which must also be shared with the connection. Plain names won’t work.

Sources

• Page property values | Notion API
• Request limits | Notion API
• Build forms in Notion | Notion Help
• Notion Integration | Tally Help