One of the most impactful dashboards in a team workspace is what I call a “Me-page”. These simple pages generally utilize Notion’s Can comment permission level, allowing new *Notion users to find and work with the content relevant to them in a single location without accidentally deleting dashboards or databases. You might think of them like a user home page.
Me-pages are often the first thing I build in a team workspace, and the thing I establish as the central page in a shared workspace. “Go back to your me-page” is something I typically teach teams to teach their colleagues and collaborators. Me-pages are the jumping off point for personal activity in a lively Notion workspace.
Why are they called Me-pages?
I call them this because they use a view filter content with a Person property containing the value Me. “Me” is a special token in *Notion filters that expands to the currently viewing user. It shows at the top of the selector when you filter a Person property.
Whichever Notion user is viewing the page will see content relevant to them. For example, a Me-page might display all on one page:
- Projects and tasks I’m assigned to
- Company-wide updates that are relevant to me or my team(s)
- Docs I’m collaborating on
- Meetings I’ve participated in
- Events I am attending
- and so on
And, of course, I here can be any member of the workspace; this page will be theirs as well.
In many team workspaces—including many of the ones I’ve collaborated in—we often see global tasks databases with separate views for:
- Tom’s tasks
- Maya’s tasks
- Jamal’s tasks
- Ben’s tasks
- …100 other employee’s tasks?
Some admins even create separate pages for each of their employees. Can you see where this might become a maintenance nightmare? Want to update all the pages for your teammates? Or add a new “feature” (perhaps linking in a new database) to their pages? It means having to do the same work for every single employee page.
Me-pages solve for this scale-problem by making a single page that adapts to the current user.
The sources of the linked databases on these pages are generally set to Can edit content permission. This allows user to edit the content in the database (add new pages, modify existing ones), but not change views or change view settings. This is generally a good practice since the default Full access permission Notion starts you with means that anyone can delete your entire data-set or systems. Yikes!
We can also use Notion’s Groups feature to create a functional group such as “Notion Editors” and extend their access to Can edit permissions. This gives you a more restricted starting point for the average member in your space and gives more control over “how things work” to administrators who are more familiar with how Notion works.
It allows you to build systems that are scaleable and less error-prone.
This is one of many good Notion permissions practices: Define Notion skill level groups along-side your team/functional groups.
For example, executives such as your CEO might have a lot of executive power but be absolutely shit at Notion. Don’t make your execs “Workspace owners” with full-access just because they hold organizational authority! It should be expected that not all employees will have the same prowesses when it comes to technical literacy, so we should think about good sane defaults on permissions to prevent too much of a free-for-all on content management.
It’s good to take a moment to note here that effective Notion permissions schemas can be quite complex (as complex as organizational/power dynamics), and therefore challenging.
Spending some time documenting your company’s skill levels categorically can be beneficial. You might even consider using a Notion database to document your internal groups and permission levels. I often do this as an administrative task that will help me as a Notion builder.
For example, here’s a basic “Access Plan” I created to document what actions groups could perform on each page in a system:
Most Notion users typically primarily need to be able to see their Tasks, Projects, and Docs. Having those displayed in three different locations can be challenging.
By using Linked Views of Databases filtered by “Person=Me”, we can bring those all into one page.
For example, my Tasks views will generally have a filter where the Assignee is “Me” AND the Completed by person property does not contain “Me”.
This allows you to have multiple assignees mark their portion of the work completed.
I like to also add a Watched by person property to many databases, which can be used as an internal favorites system. Example: I “watch” my favorite SOPs so I can refer to them readily from my dashboard(s) without having them always in my “Favorites” in the sidebar.
I don’t believe there’s a canonical name for these, but I make a distinction between Advanced Filters (“AF”) and Quick Filters (“QF”) in Notion views. Me-pages allow you to control the core presentational experience with AF’s. QF’s allow for customization of dashboards w/o users having to duplicate a template.
Me-pages give you a great starting point for your org that gives just enough flexibility for 95% of your users to get a customized Notion experience.
For the 5% of users who are editors or architects, of course Notion provides the components and you provide the data for them to be empowered to create their own private dashboards for themselves or their teams.
Ready to build a “Me-page” for your team?
Let’s do it! Watch my latest YouTube video for a build-with-me detailing how to build this from scratch including all the weird permissions edge-cases. While you’re over there, subscribe to my channel so I can bring you more of this content.
[*For full disclosure, I’m a Notion Partner, so when you sign up with my link, you also help support me and my content!]
Notion tips in your inbox