Welcome back to our ‘Building in Notion’ guide. In part one, we looked at Documentation Systems (SOPs, ops docs) This second part will focus on Core Workflows. In each of the parts you can expect the following: 

• PART 1: Internal documentation systems (SOPs, ops docs)
  
  
• PART 2: Core workflows for operations and project management (projects, OKRs)
  
  
• PART 3: Permissions and security
  
  
• PART 4: Automations and integrations

How to use Notion for: Operations and Project Management

Every team needs some form of project management structure to support operational work  -  a place to manage projects, track tasks, capture meeting notes, store working docs, and, in more mature setups, goal tracking like OKRs.

Those project management needs don’t change as you scale, but the structure around them does. What evolves is how these systems are set up, who owns them, and how much visibility different layers of the organization require. The biggest difference is whether these systems are centralized (all teams use a single set of core operational databases that you can contextualize by team using a team tag), decentralized (each team uses its own set of databases), or a hybrid of both.

What all teams need to know: establishing consistent project systems to enable streamlined collaboration

Across all team sizes, project management needs are surprisingly consistent. Teams want to know what’s in progress, what’s blocked, and what’s coming next. They need clear ownership of each task and project, context, and a reliable way to keep tasks from falling through the cracks. These systems don’t have to be complex, but they do need to be consistent to enable clear and streamlined collaboration between teams and individuals within those teams. 

Without clarity in project management, you risk falling into common traps:

• Disconnected tools and trackers: One team uses Notion, another lives in Google Sheets, someone else spins up Trello. No one knows what the source of truth is -  or worse, all of them are considered “the source of truth,” leading to duplicated work and conflicting updates. Unifying teams after the fact is way harder than building a consistent structure from the start.
• Collaboration is siloed or ad hoc: Without a clear and consistent system, collaboration depends on people tagging each other manually or sharing links in Slack (or, god forbid, email). There’s no central hub to work together, assign ownership, or track progress, which leads to duplicated efforts, missed handoffs, and constant (manual) status-checking.
• Lack of standardization and clarity: Some tasks have owners, others don’t. Deadlines are missing (and consequently missed). Priorities are unclear. And without structure, teams reinvent the wheel every time they start a new project.
• Meeting notes and docs live in isolation: Notes get buried in private pages, docs aren’t linked to the projects they support, and important context never makes it to the people who need it. Team members write things down in their private section and then wonder why no one follows their process or even knows it exists.
• Work doesn’t ladder up: Projects and tasks aren’t connected to company goals, so it’s impossible to see how day-to-day work drives broader outcomes. Meanwhile, leadership is left flying blind… without operational visibility, it’s like trusting a blind taxi driver to get you to your destination safely.

So, how do you avoid these pitfalls? 

Build a Solid and Interlinked Foundation

The first step is to build a solid and connected foundation for managing your work, which will enable greater clarity and more effective collaboration. A reliable setup doesn’t have to be complex, and most companies and teams can start with five core building blocks:

1. Projects: Linked to Tasks, Docs, Notes and OKRs
2. Tasks: Linked to Projects and Meeting Notes
3. Meeting Notes: Linked to Tasks (to track action items from the meeting)
4. Operational Docs: Linked to Projects they support
5. OKRs (optional, based on team size and maturity): Linked to Projects to track how these projects contribute to strategic company goals

Use Curated Views 

Notion makes it easy to build connected systems, as we showed in Part 1 of this guide, on documentation systems. When you link databases, you can create curated views that group all related information in one place. For example, on a project page, you can surface all related tasks, docs, and meetings. On a meeting page, you can show action items that came out of the discussion. 

What’s even better is that this connected data doesn’t just live on individual pages - you can surface it elsewhere too. For example, you can build a master task view filtered by team, status, or owner, giving you visibility across all projects, all teams, and all owners in one place.

Strategically create and organise relevant properties within core pillars 

For each of the core operational pillars (projects, tasks, meeting notes, operational docs, and OKRs), a few key properties go a long way in keeping things organized and actionable. Don’t overdo it, though - a lot of teams overengineer their systems early on, only to realize later they’ve built something so complex no one wants to touch it. Start simple, stay practical.

These are the properties we recommend within each pillar:

• Projects: Project Lead, Timeframe, Collaborators, Status, Project Type (optional), Team
• Tasks: Assignee, Due Date, Status, Team, Priority (optional)
• Meeting Notes: Date, Attendees, Meeting Type, Recording (optional), Team
• Operational Docs: Author, Status, Type, Created Date, Published Date, Team
• OKRs: Team, Description, Timeframe, Responsible

This level of structure is simple to implement but makes a big difference in keeping your workspace usable, navigable, and scalable as you grow.

Team-specific advice

Small Teams: Start centralized, using one shared setup with personalized filters. 

Smaller teams often start with a single system for everything, and that’s a good thing. All team members use a single set of operational databases, which fosters collaboration and enforces a semi-standardized structure from the get-go.

What often goes wrong is when individuals build disconnected tools inside the same Notion workspace - simply because they can or because they don’t know how to use the structure you set up for them. Notion gives everyone the freedom to create, but without guardrails, a flexibility which can quickly turn into fragmentation. And that’s a problem when you’re trying to build for team collaboration.

People create docs in their private space, spin up their own task trackers, and make systems that work for them but don’t scale with the team. As headcount grows, these siloed setups turn into bottlenecks that are tough to untangle.

Our advice? Start centralized - and make sure the team works within that shared system, through equipping them to do so, as well as setting clear expectations. Not everyone needs to build their own setup. The more aligned you are early on, the easier it is to scale without chaos.

Use one shared setup for projects, tasks, operational docs, and meeting notes across the entire team. You can always create filtered views to show each team member only what’s relevant to them - tasks they own, or data tagged to them (like meetings they’ve attended). By using a simple team property, you can also easily spin up team-specific hubs later as you grow, without having to rebuild the entire system. Even if it’s lightweight, having a unified structure makes scaling smoother later on.

Here are a few quick tips:

• Build a company-wide project management system: Build a company-wide project management system using shared databases for projects, tasks, meeting notes, and docs -  all connected and surfaced in a single ‘Company Hub’. This gives leadership visibility without fragmenting the system.
• Build a personal hub: Notion supports something that we call a dynamic ‘me’ filter on Person properties. Leveraging this functionality, you can build a single standardized personalized dashboard that only shows team members their own data. This means everyone sees only what’s relevant and tagged to them, without needing to build separate databases for each team member. 

• Introduce a ‘Team’ relation across your core databases: It won’t matter much now, but it sets you up to build team-specific hubs later. Build a Teams database and relate it to all core databases. Don’t use a select or multi-select property - those are defined on each database separately, while relations can be reused across databases, and maintained from a single source (the Teams database) as your org grows.

• Be intentional with Notion templates. One of the most common mistakes we see is teams buying multiple templates and trying to stitch them together into a working system. It rarely works well. Templates are built for specific use cases - use them for inspiration, not as a shortcut. Don’t Frankenstein your workspace. 

Quick note - Notion makes it a little too easy for users to add templates to your workspace (plays well with their key message of flexibility and “everyone can work the way they want”). Even if they can’t add them to teamspaces, they can still drop them into their private section. Set expectations early: Just because someone can use a template doesn’t mean they should. Disconnected systems in private pages lead to misalignment, duplication, and lost context. Keep it visible, keep it shared.

SMBs: Standardize system design and intentionally introduce team-specific workflows 

As teams multiply, standardization becomes a must. SMBs benefit from a centralized architecture that allows for global collaboration, while still giving teams room to build what they need. Use a shared global architecture (as described in the previous section), and just integrate department-specific databases as needed, like ‘Features’’ in Product or ‘Accounts’ in Sales, to the larger operational ecosystem. This is the sweet spot where structure and speed can reinforce each other.

Here’s our advice:

• Build Team and Department hubs: This is where the Team relation really starts to pay off. Use it to build department and team hubs, positioned inside the department-specific teamspaces. From there, you can create tailored views for each team, filtered by their work, their goals, their docs. Notion makes it easy to build custom hubs, so we recommend creating a team hub template as a starting point. Duplicate it, tweak it, and give each team a space that works for them, without sacrificing rolling up core operational metrics into a company-wide dashboard. You can still build charts to report on the number of projects per team to see capacity across the company, see the number of projects that contribute to the main company strategic goals (OKRs), and more. 

• Identify team-specific workflows and how to integrate them: As teams grow, they will often introduce team-specific workflows - either by integrating with company-wide project management systems (e.g., connecting tasks to features or sprints for product and engineering), or by adding standalone databases inside department hubs. Whether to integrate into the core workspace or build a closed system depends on collaboration needs.
• Integrated systems: If a team’s work ties closely to cross-functional collaboration - like Product and Engineering managing work in sprints - it makes sense to connect their workflows to the broader operational layer, since they relate directly to company-wide projects and timelines.
• Standalone department-specific systems: On the other hand, if a team manages internal processes that don’t require collaboration with other teams (like IT maintaining a software inventory) or houses sensitive data (like the HR team managing a job application pipeline), this data can live in department-specific databases and teamspaces (which you can lock down with Notion’s permissions), disconnected from company-wide project management. It’s still important, but it doesn’t need to plug into the core project management system.

Enterprises: Typically decentralized by design (but not disconnected)

At scale, full centralization of project management isn’t always practical, and often, it’s unnecessary. The CEO doesn’t need visibility into every detail of day-to-day operations. Department heads do (for their teams). Their job is to oversee their team’s work and roll up what matters to leadership. That’s why enterprise systems tend to be more decentralized, with each department owning and managing their own operational and project management workflows.

Everyone’s still working within the same Notion workspace, but departments will often have their own set of databases for project management. That might be because of sensitive data, and oftentimes, performance considerations.

While Notion doesn’t hard-cap the number of records you can store in a database, performance will start to lag as you approach ~200K rows - especially if your databases have a lot of properties, or if you rely heavily on computed fields like rollups and formulas. These properties query the entire related database each time they load, which gets very slow at scale.

Enterprise Notion workspaces are often decentralized by design, but still unified at the workspace level to streamline admin work, governance, and billing. Still, that doesn’t mean you have to sacrifice structure, nor skip out on connected workflows. 

Where it makes sense, connect independent teams that collaborate frequently. For example, all marketing functions might share a unified campaign system to work seamlessly with creative ops and build a central marketing calendar without duplicating data. Department-level operating systems should also follow common patterns, and OKRs or strategic goals can still roll up to leadership where it matters.

Some enterprises do choose to centralize fully - and if your org doesn’t handle sensitive data and prioritizes global alignment, that can absolutely work!

Conclusion

Efficient use of Notion can make work visible, actionable and aligned; with a proper core workflow, all your projects, tasks, docs, notes, and goals are connected in one place. Whether you’re a small team, SMB, or an enterprise balancing decentralization with shared patterns, the principles remain the same: keep it simple, keep it consistent, and design intentionally for collaboration. Now that you’ve got your workflows in place, the next critical layer of your Notion architecture is Permissions and Security, which we address in Part 3 of this guide. 

If you’d like to learn more about Notion more generally, head over to our ‘What is Notion’ article, or if you missed Part 1 of this guide, you can find that here. 

Want to learn more about internal tools and how to build them? Check out our sections on low-code tools like Notion and Airtable, or developer tools like Retool and Windmill.