Why all of our forms have their own Notion databases

With the advent of the Notion API, it’s now easy to send form data into Notion.

We capture information from dozens of forms throughout a student’s journey through Notion Mastery; everything from our intake form, to various feedback and application forms.

All our forms are hosted in Tally which has a direct integration with Notion; this means information collected by Tally can be sent straight to Notion without having to use a third party tool like Zapier.

Direct integration between Tally and Notion.

When I set up our course operations, I opted to create an individual Notion database for each individual form. Here’s why:

🖼️ Aesthetics and ease of viewing

If we fed all of the form responses into one master database (eg. our student database), it would need to have a property for every question asked, from every form – way too crowded!

Sure, if we were using one giant database we could create customized views that hide non-relevant properties, but with over two dozen forms, it would be a beast to setup and maintain.

By having form responses input into a database that is dedicated to that specific form, it is easy to distinguish the purpose behind the questions. For example, if you are looking at the intake form database, you know the answers presented are in response to only the intake form questions.

An example of some of our form databases.

📄 A single student can submit the same form multiple times

For example, we can have the same student complete the same feedback form 3 times over 12 months, without overwriting past submissions. Each of those responses show up in the feedback form database as an individual entry. Each of those entries can then be related back to the relevant entry in our student database.

An entry in the student database showing two responses to the Check In Form.

📁 Easy to archive

Imagine we required people to complete a form to apply for Notion Mastery (we don’t, but just imagine!). Say we used it for 6 months and then decided we didn’t need an application form anymore.

If the application form has its own individual database where all the responses are sent, it’s easy to archive that single database. If later on we decided we wanted to bring the application form back, we could just ‘resurrect’ that database and continue on.

On the other hand, if the responses were sent to a central, student database, and we decide we don’t want to use the application form questions anymore, we now have a bunch of properties in our database that we don’t require. In order to clean up the database, we would have to delete those properties (and therefore delete, rather than archive, all that student data).

Considerations when integrating Notion and forms

When you are setting up your forms and integrating them with Notion, consider:

  • What database set up will make it easiest for you to review and analyze responses
  • The likelihood of one person needing to submit the same form more than once
  • Whether you might want to archive your form data in the future

It might make sense to maintain a single database for form responses if you only intend to ever use a few forms and only expect a single response from each person. However, if you think you’ll be using many forms, or want people to submit the same form multiple times, a dedicated database for each form is the way to go.

Share This Post

Share on linkedin
Share on twitter
Share on email

Sign up to get updates

    Debugging Notion

    Notion moves fast and sometimes bugs or issues can get in your way. “Notion is Buggy” is a thing we say a lot here at

    Master your life and business workflows with Notion.