This is part 4 of 7 in the Notion database series. Read Part 3: The Art of Titling a Notion Database
Notion is a unique tool in that its the first of its kind to distill the creation of a web app down to 1 common denominator – the block. With this block being the atomic unit of Notion, the user freely drifts between what programmers would call “front-end” and “back-end” development. Oh yeah, in case you didn’t realize it, you’re essentially programming with Notion. you just don’t have to code. The thing is, you probably don’t ever realize it and that’s the golden ticket. The software is so easy, you don’t realize how powerful of a tool it is.
As a primer, the front end of what you build is the interface, the aesthetics, the experience, the navigation and all of that. The back end can be summed up with databases, although you could roll in a lot of other system settings like permissions and such. Databases provide the back-end because they’re traditionally out of view in normal applications. They surface in very particular ways but its usually the equivalent of the tip of the iceberg. You’re only seeing a small piece of it.
Notion blurs the lines. You can make databases just as easily as pages (don’t forget, they’re technically all just pages). You can create a table inline with your niche SOP to better illustrate the SOP. And that’s a great feature! If the database truly is only useful for that SOP, that’s a perfect use of inline databases. But often, people end up creating a new database to showcase data inline with an object type that already exists somewhere else. They’re seamlessly trying to create a front end experience but weaving a back-end framework without considering the entire back end. You wouldn’t create two HQ pages for the engineering department. You shouldn’t create two databases for projects. One database per data object (as much as possible).
Notion blends front-end and back-end building into one effortless and beautiful block-building experience. It’s no wonder that most new users don’t consider separating these two concepts. But it’s crucial for building an effective – and especially a collaborative – working environment.
Differentiating the back end from the front end is the foundation for a more concrete application and best practice – the “Global” database concept. Databases are such a critical part of a workspace that they deserve special attention. to state it again, we want one database per data object as much as possible. One project database for projects, one files database for files, and so on. This is the rule and of course there is room for exceptions. In its simplest statement, this is what a Global Database is – one database per object. But the concept encapsulates the why and how it plays out in Notion.
The practical implication of using global databases is that you leverage Notion at its best. Notion at its best is a self-serve, single-source-of-truth, cross-functional and collaborative workspace for companies. It can just as well serve individuals. but its shines in all its best colors in companies with multiple teams. One projects database servicing 5 departments with 5 teams in each and various sub-teams throughout, means that you can see and analyze projects at every level. Workers can collaborate at the most grassroots level, managers can track progress, leaders can cross-check against objectives, and seniors can aggregate it all from the top and dive in and out as needed. And this is only one vertical plane of many that highlights the benefit of global databases.
If each team had their own projects database, there would be a large gap where information stops flowing because the only way to aggregate it is by keeping it in one global database. Not to mention the other maintenance of managing permissions, views, database templates, and more.
The only exception really does come down to permissions which is due to a current feature limitation. You cannot, in any way (don’t listen to people on the internet that say you can) give someone access to only part of a database. They must have access to the entire database to have access to any page within. So it makes sense to keep some more sensitive data like performance reviews, compensations packages, and so on in a separate database, probably with People Operations or Executive. Besides this, you should always strive to create your systems “back-end” with global databases.
Read Part 5: Notion Database Views