It’s been famously said that there are two hard things in computer science:

1. Naming things
2. Cache invalidation

Don’t worry if you don’t know what cache invalidation is—it’s not important! What is important (and true!) is that the names we give things—especially in Notion—are incredibly important. And anything of utmost importance tends to be difficult.

Why naming is important (Search, AI)

You will end up with a great number of documents in your Notion space. 1,000s of tasks, meetings, notes, and more (maybe even 10s of 1,000s!). When searching via page titles (the primary way to find documents in Notion), you may find your pages, databases, and templates have a similar naming structure. This often leads to challenging search outcomes (see below).

In Integrations where you need to search for databases or pages, it’s helpful to have naming and visual cues that tell you where something is a database or a page or a template.

It’s also incredibly helpful when it comes to creating relations in databases. If you have 100s of similarly named databases, finding the one you want to connect can be challenging.

Developing a Notion Naming Schema

Even in a personal space, it’s important to have a set of conventions you’ll use to name your pages and databases in Notion. Where it’s especially important is in shared workspaces, where many people have their own versions of databases and similarly named pages. Conventions help your team and you decide what to name things and how.

Whether finding files via search (whether its linking pages, picking pages from a relation picker, or searching using Notion’s global search) or Notion AI and the AI-backed Q&A feature, Notion operates most effectively when you have a reliable schema for naming resources.

Below you’ll find my personal ethos for naming in Notion. I typically call these “good practices”. There are “best practices” in Notion, but workspaces vary so wildly, I’m hesitant to call them this. The best practices are the ones you develop from good practices (take that as you will).

Naming Databases

Recommendations:

• Database names should generally be pluralized; Things, not Thing. This indicates that it represents a collection of pages rather than a single page.
• I highly recommend prefixes or suffixes to indicate key shared databases.
  • One strategy is suffixing names with DB, so we might call this Things DB.
  • Another useful naming strategy is prefixing. Prefix with a 2–3 letter code, e.g. DB Tasks, where DB can stay as DB or you can replace it with a short version of your company name.
  • For instance, our company is called Oki Doki, so we might prefix all databases with OK or OD or Oki, so we might have databases like:
    • OK Projects
    • OK Tasks
  • This helps to differentiate between shared system databases and personal (and other) databases when searching and creating connections between databases, e.g., a personal Tasks database and the company’s OK Tasks database.

Naming Templates

Recommendation: Use a prefix/suffix strategy for database templates.

I tend to prefix all template names with -> so they are easily recognizable when searching. When you type - followed by > in Notion, it’s rendered as a beautiful arrow: →

Notion includes templates when you are selecting items from a database and also in global search (whether this is intentional or a bug is uncertain), so being able to notice them easily with this convention can be helpful.

Other methods include prefixing the name of the template with Template: and others sometimes prefix with something like [TEMPLATE].

What’s important is that you standardize.

🔍 Search Indexing It should be noted here that it takes time for pages to be added to the search indices, so don’t expect your page to show up in search immediately after creation. Sometimes pages have to be revisited in order for them to be indexed. This seems like a bug to me (see below), but uncertain.

Posting this to see if anyone else in Notion-world has been experiencing this for months now…

Notion AI is amazing, but search in Notion seems to be fundamentally broken many places I wonder how effective the AI stuff is if it can't find pages actively. Here's an example I'm… pic.twitter.com/03IwCD0DjM

— Benjamin Borowski👨‍🚒 (@typeoneerror) February 5, 2024

Naming Properties

Recommendation: have a strategy for naming properties that indicates what purpose the data stored in the property serves.

For example, a property of type Person named “People” is not very descriptive. What type of people? Why are people being assigned to this property? Perhaps you could name this:

• “Reviewers” — indicating a list of people that need to review a document
• “Assignees” — indicating a list of people who will be performing a task

These are both much more descriptive names than “People”.

Booleans

Anything that returns a true or false value (checkbox properties or formulas that return a checkbox) I recommend naming like a question.

Example: if you have a property that checks to see if any Tasks are related to a page, you might name the property something like Has Tasks? (including the ?).

Dates

Use a name that indicates what the date represents. For example Date is not a great property name. Whereas Due by tells us more about what the date indicates.

I tend to use at or by prepositions to indicate actionable dates.

Advanced auto-properties

For advanced auto-generated properties, pick a naming strategy to use across all databases.

My personal style which I adopted from the Ruby on Rails “timestamp” column names:

• “Created by” → Created by property
• “Created at” → Created time property
• “Updated by” → Last edited by property
• “Updated at” → Last edited time property

One way to standardize on this is to have a “Baseline” database which contains all the automatic properties in it. When you are making a new database, simply duplicate this database so you don’t have to redo all that preparatory work each time.

My Baseline database also includes a Person property called “Favorited by” which I use to create an internal dashboard “favorite” system.

Rollups

Not a requirement, but consider naming rollups after the related database they are referencing. Some folks might do name them something like:

“Tasks / Count” to indicate that the Rollup is targeting the “Tasks” relationship and performing a Count all calculation on the property. This makes it easy to tell which relation the rollup is targeting.

I’ve seen folks use / or . or even > to indicate rollup relations.

I usually like to arrange rollups underneath the relations they are referring to in the property list in page view. This is a helpful visual organization method to keep related properties together visually (my kingdom for manageable property groups, Notion!).

Statuses

It’s good to think about the tenses of your status group options and select options, and whether they are clearly actionable. For example, consider the implications the different statuses below might have:

• Review
• In Review
• Needs Review
• Reviewing

Is your workflow complex enough that you need interstitial statuses?

• Needs Review (Pre)
• In Review (During)
• Reviewed (Post)

Or can you get away with one to represent the entire review process? What information might be lost in the process with or without these options?

Property Icons

You may be tempted to add custom icons to all your properties. I think it’s generally okay if your coworkers are quite familiar with Notion and know how to recognize a relation picker at a glance. But for novice Notion users (to be honest, I sometimes have to look strongly), leaving the default arrow icon can be a helpful way to delineate relations from other properties.

Naming Database Views

When creating views, do your best to name them after the Filters that are applied to the view. This can be helpful to discoverability.

For example, if you have a filter that is filtering out only the projects that are not completed, you might call the view “Active Projects”. Consider that “Active” might be a good name if all the views in the linked views are from the Projects database, but if you have different databases in the views, it’s good to add a database name to the View name as well.

👉 Consider the difference between personal pages and shared pages here. Where you might have built-in understanding of what a view represents, the same is not always true for your teammates.

Note that using the view description feature in Notion can be a great addition to a well-named complicated view!

General Naming

Stick with a case system throughout your workspace. For example, it’s not entirely terrible, but it can be visually arresting to see a bunch of pages like this:

• journal feb 5
• Journal: Feb 4, 2024
• JOURNAL: Feb 6, ’24
• Untitled

Because of the way we scan text visually, this can make it harder to scan quickly. Standardizing on format and case in page, database, and property titling can go a long way to having your space feel orderly and approachable.

• Journal: Feb 5th, 2024
• Journal: Feb 4th, 2024
• Journal: Feb 6th, 2024

Ah, that’s nice.

Action-Oriented Spaces

I like to think about designing action-oriented spaces. When we take action, we’re typically performing a verb on some sort of noun.

For example, if we have an Ideas database, we might create a page to Capture Ideas. We might reverse that and call it Idea Capture. In both cases, the operative verb is to capture.

At one point in Notion Mastery’s early history we had a lesson on goals and goal planning and we had templates for Goals (a database) and Goals (a page for planning and setting our goals). In order to promote better searchability and clarity, we renamed the second page “Goal Setting”. This makes it much easier to tell between our document store (”Goals”) and the action we’re taking against/with our document store (to “Goal Setting”).

Documenting Your Naming Conventions

Conventions are only really as good as their enforcements, so while you might like the ones you’ve decided on, if one of your co-workers has no idea about them, how good will they be in practice? Probably not very. Given that Notion doesn’t have any kind of property value validation, what’s the best way to enforce your new conventions. I’ll throw you some ideas from kinda easiest to hardest:

SOPs

Add an standard operating procedure that contains all your naming conventions as a list. You might even make one block per convention and use Synced Blocks so you can paste the same content in key dashboards and database templates.

Descriptions

Add conventions in your descriptions.

• Add key naming conventions in database descriptions.
• For expected property values, add a description to properties indicating the titling conventions.
• Add descriptions to your Status options. This is a not-so-well-known feature of Notion added recently, but this can have a huge impact if the workflow is unclear to new members.

Build Audit Tools

You can also build tools that are meant to help you audit the data in your databases. These are one of my favorite dashboards to build for clients and are part of a healthy Notion review practice.

You could even add a formula to ensure that a property is valid. For example, if I always watch my Journal Name property to look something like “Journal: Feb 5, 2024”, I could use a regular expression in a Is Valid? formula property to test the entry:

My audit tools could then show a view which shows me any entries where the Journal page is:

• missing a Date
• has an empty Name
• Is Valid? is false