When I was setting up my *Notion workspace for the first time back in 2018, it was Tiago Forte’s PARA method that helped me give my workspace some much needed structure. It provided a helpful starting point that I was able to adapt to my needs, and to Notion’s unique functionality.

Tiago Forte recently released his new book on the PARA method, so we thought it would be helpful to dig into what the PARA method is, why you might want to use it, some of the key challenges, and how to effectively apply it to your Notion workspace.

What is PARA?

PARA is essentially a tool-agnostic system for organizing all the information in your life. PARA stands for Projects, Areas, Resources, and Archives.

Here’s how Tiago defines PARA: (quotes from the author)

PROJECTS: A Goal with a Deadline
Projects you’re actively working on – short-term efforts (in your work or personal life) that you take on with a certain goal in mind.

“No matter how wide-ranging your responsibilities are, you can always break them down into smaller projects.”

AREAS: A Standard to Maintain over Time
Areas of responsibility – important parts of your work and life that require ongoing attention.

“This is the realm of daily habits, meaningful rituals, and timeless values that transcend any particular project.”

RESOURCES: Topics of interest that may be useful in the future
Resources on a range of topics you’re interested in and learning about.

“Taking into account the importance of utility, resources can also include “assets” such as stock photos, product testimonials, code snippets, typography samples, or a “swipe file””

ARCHIVES: Inactive items from the other three categories
Archives include anything from the previous three categories that is no longer active, but you might want to save for future reference.

“Don’t think of the Archive as an “idea graveyard” where information goes to die. Your archives represent the sum total of your life experience, a treasure trove of hard-won lessons and profound insights you’ve gained from both successes and failures alike. I guarantee it will contain useful material you can reuse and recycle in future endeavors.”

The Challenges of PARA in Notion

Where does [thing] go?

The idea is that if you have a piece of information you need to save, you can ask yourself:

Is this supporting an active Project/Goal?
YES: Save it to the Project folder
NO → Will it help me uphold an area of responsibility?
YES: Save it to that Area folder
NO → Will it support of one my interests or curiosities?
YES: Save it to the Resources folder
NO → Delete it!

Now, this is fine for organizing folders on your desktop and such, but with Notion, it’s not quite so simple. Why?

*Notion is a dynamic application that doesn’t require your data to only live in one place like a folder on a computer.

Linked Databases give us immense power to filter and view information in different ways depending on the databases properties. Notion databases give us the ability to add metadata to our information that can make it even easier to find and connect projects, areas, and resources together in helpful ways.

Notion databases also add a layer of complexity that mean we must adapt PARA to work with Notion’s unique features, functionality, quirks, and limitations.

Let’s use a specific example:

Content Marketing is a personal topic of interest (Resource), but it’s also an Area of responsibility for our business (part of the Marketing activities), which means it also has active Projects associated with it. If I’m saving information, reference material, or assets relating to content marketing, where should that information be saved/stored?

PARA is most useful in the context of Notion if you don’t interpret it literally.

For example, you don’t need four pages in your sidebar, or four pages in a database named Projects, Areas, Resources, Archives.

PARA was designed to be flexible and fluid.

“The contents of PARA are constantly flowing between different categories as your needs, goals, lifestyle, and priorities shift.”

— Tiago Forte

Tiago recommends regularly moving things between the different categories depending on whether or not they are supporting an active project, upholding an area of responsibility, or needing to be shared etc. Again, this works when we’re talking about folders, but in Notion, grouping things into databases is what really allows us to supercharge our workflows.

The beauty of storing things in databases is that we have the capacity to gather more context, reflect and review, and see patterns over time in a way that would be challenging without.

We may want:

• Visibility into how many projects get archived within a specific timeframe, or by a specific team member.
• An easy way to see all projects, resources, or documents relating to a specific topic/tag.
• To review project resources and reuse them in another project, without losing the relations between those the two databases.

The problem with how Notion stores data is that moving pages from one database to another means losing any relations that were attached to that data (womp womp)!

Notion’s functionality (and limitations) mean a slightly different approach is necessary from an implementation perspective in order to truly leverage the power of databases.

Personal or Shared?

In the context of teams, Tiago recommends having a personal PARA system and a separate shared/team PARA system. This is fine in theory (and makes sense for large teams to have their own PARA system), but this can get complex for small business owners that don’t have such a distinct delineation between work/personal.

Many people are looking to manage both personal and shared data in the same workspace. (Most of our Notion Mastery students are business owners trying to manage the complexity of their personal lives and business lives in one place seamlessly, so this is a very common challenge).

Does a small business owner need to maintain two Notion resource hubs, one for personal stuff and one for their small team? What happens if you want to move something from a private database to a shared database (remember, you lose any relations you’ve created to that database page)?

Where/how we store information in Notion completely depends on whether or not you’re in a personal/private or shared/team context, and whether or not you want/need to keep historical context.

Notion also has certain limitations when it comes to sharing and permissions, so access is usually the first consideration when determining the structure of your workspace environment, and where data needs to be sourced.

The biggest limitation currently is that database access is all or nothing.

You can’t give partial access to databases. You can adjust access permissions on individual pages within a shared database, but you can’t, for example, limit visibility on a specific view of a database.

This means if you decide to have a single task database that you share with your team, you can’t easily restrict your team from viewing your personal tasks (without manually restricting access on every single newly added task – yikes!). But most people don’t want to maintain two task databases… so what to do?

PARA needs to be heavily adapted in a Notion context mostly because Notion’s sharing and permissions can make mixing personal/private and team/shared information challenging (which is exactly why Tiago recommends keeping them separate), but having two of every database isn’t necessarily an optimal solution either.

As always with Notion, the best approach depends on your unique circumstances. How PARA is applied in a Notion workspace will completely depend on:

• Your tool stack
• Your type of work
• Your team size
• Your preferred way of working
• How much you need to share / keep private
• How much you care about historical context

How I adapt PARA for a complex Notion context

There’s lots of wiggle room for interpretation and implementation when it comes to PARA. I’ve made some adaptations to the system based on Notion’s features and limitations, and based on some key criteria:

• My Oki Doki Notion workspace is primarily a shared team account (3 full-time employees).
• I’m an owner of the account.
• The majority of Projects and Actions in the account are for a work context.
• All of my personal areas are also managed from this account (private pages).
• We manage our family/household activities from this workspace (shared Pages only visible to my husband and I).

Overview of our PARA Notion setup

• The Projects database is one of the most important and highly utilized database in our workspace. All projects are designed as dashboards that contain linked databases which are connected to the project including: Actions, Library, Notes + Ideas, Documentation, and others as needed.
• Areas is a flexible term that comprises three sub-categories:
  • Areas are my personal, private pages inside a personal dashboard in the private section of the workspace (no one else on the team can view). These pages contain both private databases visible only to me, as well as our shared team databases (Goals, Projects, Actions, Library, Notes + Ideas, etc).
  • Household is our shared Teamspace for all household related activities, resources, etc. It lives in the main workspace sidebar, but is only visible to Ben and myself.
  • Departments is a database that represents our work areas of responsibility (everyone on the team has access). These are designed as dashboards containing all projects relating to that area of responsibility, as well as any routine actions that help uphold and support the maintenance of that area, as well as any resources specific to that department. For example, our Content database is housed within the Marketing + Sales department.
• Resources is essentially a shared team knowledge base made up of a group of databases that help support research, areas of interest, and moving projects forward. The most utilized databases in this category include:
  • Library: all content saved/clipped that comes from external sources, including articles, YouTube videos, online courses, books, etc;
  • Notes + Ideas: all self-created notes, ideas;
  • Topics + Tags: a global database linking most other databases in the workspace to make it easy to find related information, projects, etc.;
  • People: a database that acts like a CRM and contains all shared contacts including clients, friends, colleagues, contractors, etc.
• Archives is nothing more than a Project database Status property. Projects get archived when they become inactive but have not been completed. Moving a project to the archives is an act of changing the Status to Archived, rather than moving the entire project itself (more on that below).

Here’s how it looks in more detail:

PROJECTS

The Projects aspect of PARA in Notion relies heavily on two databases: Projects and Actions (You can also integrate a third Goals database, but that’s a rabbit-hole for another day!).

The Projects database is one of the most important databases in the workspace (it is the lifeblood of our shared team workspace). The Projects database has a two-way relation to the Actions database.

Projects are how we group tasks together in Notion. Using a relation property, all projects in the Project database are related to the actions (from the Actions database) required to complete the project.

Everything in your life is a project, so nearly everything should be added as a project into this database.

Most of us have many more commitments than we realize; when we don’t break up our responsibilities into projects, we end up thinking we have much more time than we really do.

Projects have database properties like:

• Owner: could be just me, or anyone from my team
• Date: start → completion
• Scope: how resource intensive or time-intensive is this project.
• Department (Work Area, a database relation): Design, HR, Operations, Client Services, etc.
• Priority: reviewed + adjusted weekly.
• Sub-Projects (”Self relation” to the Project database): any smaller projects related to this one if there are any.
• Goal (database relation): the bigger Goal that the project supports.
• Actions (database): the related tasks and events required to complete the project.
• Status: A status property indicating whether the project is in discovery, or whether it’s active, ongoing, completed, archived, etc.
• Status Updates: A small text field that the owner updates weekly as part of a weekly review. This helps the team see at a glance what’s happening with the project.

Actions

The Actions database includes all tasks (to-dos) and events (time-based meetings and events from your calendar). This database is essentially your to-do list. Generally speaking, all actions should be associated with (related to) a project.

AREAS (private)

An area of responsibility is “a sphere of activity with a standard to be maintained over time.”

This is where things start to get a tricky and are open to interpretation depending on your unique needs:

• Is this a team workspace, and are you the owner of the account?
• Is your account primarily a place to get work-related tasks done?
• Are you sharing your workspace with other people, or is this primarily a personal workspace?

Areas are private and personal.

My personal Areas are unique dashboard pages inside a PERSONAL dashboard page in the private section of my workspace sidebar.

Using Notion’s Wiki feature (read more about it here), I converted this Personal dashboard page into a Wiki, which creates a hybrid page/database effect where your child pages AND databases can contain more metadata. It’s a way to essentially create an index of all databases, pages, and sub-pages contained within that Personal page.

(This is totally optional – before the Wiki feature was launched these Areas were simply Pages in my Personal dashboard.)

I like to tuck all source databases into a toggle at the bottom of the page called “Databasement”.

Since these areas are private pages, they do not have relations to our shared team databases.

Some Areas have Projects.

Since many life areas have projects and actions associated with them, I still want to be able to manage those (without cluttering up the team workspace and relations with my personal stuff).

Inside our shared Projects database I have three projects that are for my personal use, each with a Status of Ongoing:

• Life Admin: a catch-all project for all personal tasks (visible to only Ben and I)
• Health + Wellness: a project for any health + wellness related activities (e.g. Softball games, Spa day, Doctor’s appointments, etc)
• Personal Development: a project for tracking all notes and actions related to personal development and courses I’m actively studying.

(Optionally, you could use a single Life Admin project for all three categories)

By creating projects for these areas, I’m able to utilize all the properties from the Project database structure, while using the Status property to mark the project as ongoing, allowing us to blur the line between projects and areas.

Hopefully you can see how you don’t have to be so rigid with the categories. For us it’s all about ease of use, access to the information, and ability to add new tasks quickly as needed.

Here’s a linked view of all projects in the Project database with a Status of “Ongoing”. The team won’t be able to see my three private Projects, and Ben can see Life Admin only (shared household admin).

Generally speaking, I add my personal tasks to our shared Actions database. If it’s something I really want to keep private, I’ll remove the team from the sharing settings on the task page itself (but it’s pretty rare that I need to do so).

If you want to work with separate task databases for work and personal, you could create a private task database in your personal dashboard page, and create a linked database inside the private Life Admin project, so it’s always quickly accessible from the project page, but no one else will be able to view it since the source lives in your private page.

Some Areas are shared.

Technically this is an “Area”, but it lives in the sidebar as a Teamspace, because its a shared Area.

Food is also a big part of household activities, so a custom dashboard called FOOD HQ lives in that sidebar area for quick and easy access. It has things like a pantry manager, recipes, groceries, tips + tricks, and favorite cooking videos, etc. All household and food-related projects, resources, and reference material is separate from all other parts of our Notion workspace, because the context in which I use and access that information is unique and doesn’t need to be connected to our main team databases.

I’m not typically thinking about recipes and food prep during my workdays, and I don’t need to see my work tasks on weekends when I’m in food preparation mode. Groceries are typically managed on my iphone or ipad from the kitchen or living room, so there isn’t as great a need to have this Area connected to other parts of my personal or team workspace activities.

TEAM AREAS (AKA DEPARTMENTS)

We created a database called Departments which essentially represents our team Areas. All Projects are related to one of these Departments.

Each of these is a unique dashboard that displays all of the Projects, Actions, and Resources related to this dashboard, as well as any unique source databases and pages.

For example, the Marketing + Sales page is a dashboard that houses our Content database, Media Kit, Marketing Analytics, Case Studies, Affiliate Links, et al. The Content database is displayed as a linked database in calendar view for quick access to our publishing calendar, followed by any active projects and actions related to this department.

Client services features our People database and Consulting pipeline, as well as quick links to our consulting offer pages.

Each page is designed to optimize for the most frequently performed workflows and most accessed resources.

RESOURCES

For our setup, we don’t just see resources as “topics of interest,” but more as a team knowledge base for all reference materials, research, notes, ideas, topics + tags, assets, swipe files, people, etc.

Anything that we reference as examples, inspiration, or reference gets collected in one of the key databases in this section (which we refer to collectively as the Knowledge Base), and this gets related to active projects. The Library is the catch-all reference database where most things get clipped to.

By streamlining your workspace into a few core databases, you make it might easier to relate information together and find it quickly. The more databases you have, the more likely you are to struggle to answer the question “Where do I save this?“

It’s important to find a balance, which is not always easy to do (especially when you’re working with a team).

You could certainly keep everything in a single Library database, but we’ve found that a little more specificity can sometimes be helpful if you have activities that are unique your business (Swipe files if you do a lot of content marketing, etc). It also helps keep the number of properties in your databases minimal and streamlined. Often when you store loads of different types of content in the same database, you’ll run into issues with overloading the data conceptually speaking. You end up with tons of properties that don’t make sense and clutter up your data.

If it’s an example of copywriting, it goes into the Swipe File database. If it’s a topic, it becomes a page in the Topics + Tags database. If it’s any kind of information to be consumed, read, listened to, watched, studied, etc, it goes in the Library. If it’s an idea you generated, or a note you wrote, it goes in the Notes + Ideas database.

The Library and Notes + Ideas have relations to the Projects and Actions databases, so all projects can have associated reference material and notes/ideas. All of these have a relation to the Topics + Tags database which acts like a connective tissue across nearly all databases.

So while we don’t have a database called “Resources” that is specific to topics of interest, we use the concept of resources but adapt it to include all reference material that helps us across all parts of the business.

ARCHIVES

Archives is pretty straightforward: Projects get archived when they are no longer being worked on.

“Archive” is a Project Status property. This allows us to filter our linked database Project view to display anything that doesn’t have a Status of “Archive” or “Complete”.

By keeping Projects in the Project database, we’re able to retain all of the metadata associated with that project. Things like the date created or completed, notes + ideas relating to it, related resources and assets from the Library, Actions associated with the project, and so on.

These sorts of things can be especially helpful if you do similar projects and want to reference previous actions, or do time estimates for future projects.

The only time you might want to create an Archive page or database would be if you want to clear out Projects older than 1-2 years old and want to remove them from showing up in your database searches altogether, or if your team tackles a high volume of projects with similar keywords in the names.

Remember that moving pages means “losing” the view of the associated metadata. If you’re okay with that, you’re welcome to move the pages as you see fit; just be aware that this can cause frustration if you’ve related the project to a number of other databases.

Make it work for you

This is the PARA adaptation that has worked in our workspace for the past few years.

As an advanced user I’m able to carefully mix private and shared data across different databases, but this isn’t necessarily the best or only way to set things up.

Remember that you’ll get the most out of the PARA system if you use it as a starting point, and don’t take it so literally.

Notion is powerful but it has its quirks and requires some know-how in order to apply PARA effectively.

Making things feel simple and easy in Notion from a workflow perspective is a complex process. Notion’s features and functionality mean endless opportunities and customization when it comes to how you structure your data. But if you don’t have experience with systems design, user interface design, or user experience design, it’s easy to make a mess of things.

This is why Notion Mastery exists: to help you not just master Notion (the tool), but to develop the systems thinking and organizational principles that influence the way you design your work.

If you’re excited about the idea of building up your systems knowledge, workflow design, habits, and routines in a way that is sustainable long-term, you should join us for the year long course experience.

Become a more thoughtful designer of your daily workflows with Notion Mastery.

---

---

[*For full disclosure, I’m a Notion Partner, so when you sign up with my link, you also help support me and my content!]