Is Notion a Viable Choice for Team Collaboration in China

Introduction

For the past few years I rarely talked about using Notion for team collaboration. The reason was simple: there were too few granular levels of permission control. Especially when it came to multi-person database collaboration, permissions were either too open or too closed — no middle ground — which made many real-world scenarios impossible to handle in Notion.

The good news is that over the past year Notion has steadily filled in the gaps in its permission system, introducing more granular and flexible access controls. Combined with what is arguably the strongest knowledge-base Agent capability on the market, these two factors made me seriously ask:

So I spent several days testing every Notion collaboration scenario I could think of, and finally wrote this article. If you happen to be researching the same question, this should help.

Here is what this article covers:

• Notion's account system
• Page sharing rules
• Database permission rules
• Members and teamspaces
• The actual collaboration experience
• What kind of teams Notion suits

Notion's Account System

First, we need a mental model of Notion's account system.

One email can register one Notion account, and one account can create multiple workspaces.

Each workspace is a fully functional Notion notebook with completely independent data. If you have used Obsidian, a Notion workspace is roughly equivalent to an Obsidian Vault.

By default, you are both the admin and a member of that workspace. If you are the only person who will ever use your Notion — with no sharing or collaboration — this article can end here; you can skip the rest.

But if you ever need to share a page with someone else, you will need to get familiar with Notion's permission system, which looks complicated at first but is actually simple once you get it. Let's start with the smallest unit of permission: the page.

Page Publishing and Sharing

Every Notion page can be either shared or published:

• Publish: anyone with the link can access the page
• Share: only invited people can access the page

When you invite a user to share a page, they become a guest of that page, and you can assign one of four permission levels: Can view, Can comment, Can edit, Full access. The first three are self-explanatory. "Full access" also lets the guest invite other people into the page.

So if you don't want the page to spread further, "Can edit" is usually enough.

If you only need to share a single page, things are simple. But once your pages have a hierarchy — parent pages with nested sub-pages — permission behavior gets slightly more complex.

Parent and Sub-Page Permissions

The Basic Rule

Sub-pages inherit the permissions of their parent page by default. If you share a parent page with someone, that person automatically gets access to every sub-page beneath it.

However, you can enter a sub-page and assign different permissions specifically to that sub-page. For example, you might give someone "Can view" on the parent page, then upgrade them to "Can edit" on one specific sub-page — or revoke their access to that sub-page entirely.

Breaking the Inheritance Chain

Once you set a lower permission level on a sub-page than on its parent — say the parent is "Can edit" and you set the sub-page to "Can view only" — the inheritance chain between parent and child breaks.

After that, even if you upgrade the parent page to "Full access", the sub-page permission will not change, because the chain is already broken. You have to go into that sub-page and click Reset to restore inheritance from the parent.

The same logic applies inside databases — but the database unit adds one more layer of complexity on top of pages.

Database Sharing and Collaboration

The Basic Rule

Every entry in a database is essentially a page, and the inheritance logic matches what we covered above. Share the whole database and the user sees every page inside; share only one page and the user sees only that one.

Likewise, if you manually remove a user's permission from one page, then later grant "Full access" to the whole database, that page's permission will not be restored automatically — the same "broken chain" behavior.

Databases also have a new permission called Can edit content, which lets a user edit the content inside database pages but not the database structure itself — they can't delete properties, change views, adjust sorts or filters.

So if you want a collaborator to fill in content normally, but don't want them to accidentally destroy the database's structure, "Can edit content" is a safer choice than "Can edit".

Read-Only + Can Create

Suppose you built a requests collection database in Notion and want everyone on the team to submit requests. You give everyone "Can edit", but the next day you find that someone modified someone else's request, someone accidentally deleted several pages, and someone else messed up the view's sort settings.

You want to take away editing rights, but once you switch to "Can view", people can no longer submit new requests.

Notion provides a combination for exactly this scenario: give the user "Can view" on the whole database, and additionally allow them to create new pages. This way users can see every page in the database (but not edit them), and they can create new pages — with edit rights only on the pages they created themselves.

Note, however, that "Allow creating new pages" requires the user to have at least view access to the whole database. If you only share a few specific pages instead of the whole database, they cannot create new pages there even with the option enabled.

So what if you want users to create pages but don't want them to see the entire database?

Option 1: Create a standalone page and share it

1. Create a new page and embed a linked view of the database inside it
2. Filter the database view to show only the pages the user can access
3. Share that page with the user

Now they can see the filtered database and create new pages in it, but cannot access pages outside their scope.

Option 2: Create a form for the user to fill out

1. Create a new form inside the database
2. Share the form link with the user, and they can submit new entries (creating new pages)

Finer-Grained Database Permissions

Everything above requires you to figure out who should get which permission and then set it manually. Notion also offers a different approach: let permissions follow your business logic.

In a database, you might assign each page fields like "Owner", "Reviewer", or "Client Account" — fields that reflect your business relationships. Notion's Page-level access control can translate those business relationships directly into permission rules.

Whoever is the creator gets full access; whoever is the owner gets edit access; whoever is the reviewer automatically gets comment access.

When a project is handed over from employee A to employee B, you just swap A for B in the "Owner" field, and edit access for that page automatically transfers to B.

Concretely, here is how to set it up:

1. Create a "Person" property in the database

2. Open a database page and add the owner to the "Person" field

Then in the database's Share menu, find Page-level access, and create a rule for the "Person" property — for example, "Can view". Once the rule is active, anyone added to the "Person" field of a page automatically gets the corresponding "Can view" permission.

At this point, we've covered Notion's permission capabilities at the single-page and database level. From single-page sharing, broken inheritance, and database permissions, to person-field-driven automatic assignment — this is enough to handle most content-level collaboration needs.

But most of the operations above are performed in "guest" mode. What is a guest? When you invite someone by email to view or edit a page, that person joins your workspace as a guest by default. They can only see content you explicitly share with them and have no awareness of the overall workspace structure.

Guest mode is fine for small-scale collaboration, but once a team starts forming properly, sharing pages one by one is no longer enough — you need a more systematic permission approach. That's when members and teamspaces come into play.

Teamspaces

Open Notion's sidebar and you will see two sections: Private and Teamspaces. Private is self-explanatory — only you can see it. Teamspaces can be opened up to other members.

Despite the "team" in the name, teamspaces aren't only for collaboration.

You can use them as top-level folders to separate different types of content from your Private area. For example, you can create different teamspaces for different themes, and the sidebar immediately shows the structure — no need to drill down through layers.

So even as a solo user, teamspaces as top-level content dividers are already useful. And when you do need multi-person collaboration, you can stack permission controls on top of that foundation.

When Guests Aren't Enough

Everything we covered so far — page sharing, database permissions — solves one question: how do you open up some content to someone else? The guest mechanism works well for small-scale collaboration, especially for short-term partnerships, external communication, or scenarios where people only need limited access.

But when collaboration becomes a long-term thing, you start asking: should this person enter my entire workspace and continuously participate in content creation and organization here? Once you reach that point, the guest role isn't enough — you need the next tier: members.

Inviting Members

There are two entry points for inviting someone to become a member in Notion:

1. Invite them as a "workspace member" from the workspace settings

2. Invite them directly as a member of a teamspace from within that teamspace

Either way, each new member you invite requires a paid seat. They also need a Notion account (an email) before you can invite them.

Once they accept the member invitation, your workspace will appear in their account.

They can click into this collaborative workspace, where they have their own independent Private area. Each member's Private notes are invisible to everyone else — content created there is visible only to the creator.

They can also see the teamspaces you created.

But as the image above shows, some teamspaces they joined automatically, while others only appear in a list and require a request to join. Why?

Back to your view: when you create a teamspace, you can set its visibility.

Different visibility settings fit different needs:

1. Default: the moment a new member joins the workspace, they automatically become a member of these teamspaces — no extra action required. If your team has an "all-hands announcements" or "company knowledge base" teamspace, setting it to Default means you don't have to manually add new hires every time.
2. Open: new members can see it in the sidebar and must click to join. Suitable for teamspaces where "not everyone needs it, but anyone interested can add themselves" — such as interest groups or cross-department projects.
3. Closed: new members see the teamspace's name but must get admin approval to join. Suitable for teamspaces with clear ownership like "Design Team" or "Finance", where you don't want random people walking in but don't need to hide it either.
4. Private: people who aren't invited don't even know it exists. Suitable for executive discussions, compensation plans, or confidential projects.

So the earlier behavior makes sense: some teamspaces a new member joined automatically because you set them to Default; some only show the name and require a request because you set them to Open or Closed; and teamspaces you don't want them to know about can be set to Private.

What Members Can Do

What a member can actually do after joining depends on the role you assign.

Suppose you give them "Can edit". They will find they can edit page content in the teamspace, but when they try to drag a page in the sidebar to a different location, it won't move; and when they try to invite a colleague in, there's no invite entry point.

That's because each capability in a teamspace — editing pages, moving pages, inviting members, creating sub-pages, and more — is a separate toggle, and you can decide one by one which ones to expose to regular members.

As the teamspace owner (creators are owners by default), you have all the capabilities. So if a member says "I don't see the button I'm supposed to", it's probably because you haven't enabled the corresponding toggle.

Groups

All the permission operations above — sharing pages, setting database permissions, managing teamspace members — are done per individual. That's fine when the team is small, but as it grows, you'll notice you keep doing the same thing: every new hire means sharing the same pages, databases, and teamspaces all over again; every departure means revoking all of them one by one.

Groups solve this. You put multiple members into a group and then assign permissions at the group level. When someone new joins, add them to the corresponding group and they automatically inherit every permission that group has; when someone leaves, remove them from the group and their permissions are revoked automatically.

Creating Groups

You can create and manage groups under Notion Settings → People → Groups. You can organize groups by department ("Design", "Engineering", "Operations") or by role ("Management", "Interns"), and so on.

How to Use Them

Once a group exists, almost anywhere you can assign a permission to an individual, you can also assign it to a group.

Earlier, when sharing pages, we invited individuals by email. But if you have a doc that the entire Design team needs to see, just add the "Design" group to the share list. When someone joins the Design team later, adding them to the group automatically grants them access.

The database share menu likewise supports groups as the permission target. Want "Operations" to have view-only access to a database? Just set that group's permission to "Can view" — no need to configure each person.

Teamspaces support groups as members too. Create a "Tech" teamspace, drag the "Tech" group into it, and everyone in the group automatically becomes a member.

You can also @ an entire department in page comments or inline comments, sending a notification to the whole group — no need to mention people one by one.

The Actual Collaboration Experience

That was a long section on permissions, but without it no workflow can be built. What truly decides whether a team stays in Notion, though, is the day-to-day collaboration experience.

So let me briefly walk through what you actually get if you choose Notion for collaboration.

Real-Time Co-Editing

Notion supports multiple people editing the same page simultaneously, with no overwrite or conflict issues. Every edit syncs to everyone's screen in real time — no refresh needed. You can see other people's cursor positions and what they're typing, and the page header shows avatars of everyone currently viewing or editing.

Notion also has complete page edit history. You can view a snapshot at any point in time, or roll back to any previous version. The free plan keeps 7 days of history; Plus keeps 30 days; Business keeps 90 days; Enterprise is unlimited.

Asynchronous Comments

Notion's in-product communication is mostly based on comments, which come in two forms:

• Page comments: posted in the discussion area at the top of a page
• Inline comments: highlight some text in the page and add a comment right next to it

Both support @-mentioning members or groups, and the mentioned person will get a notification both in the notification center and via email.

For async collaboration around documents, this system is enough. Comments are naturally pinned to the content, so context isn't lost — much more efficient than discussing a document detail in a chat group. Especially when you're iterating on a draft through multiple rounds, each round of feedback can be anchored to a specific paragraph — no more "which paragraph were you referring to?" friction.

Suggested Edits

Besides comments, Notion has a feature called Suggested Edits. Anyone with "Can comment" or higher permission can suggest adding, modifying, or deleting content directly on the page.

Suggested changes are marked in the page as "additions in blue" and "deletions in gray", with a small card next to the paragraph. The owner (or anyone with edit permission) can accept or reject each suggestion, or reply to discuss inside the card.

Archiving Pages

After a team has used Notion for a while, the workspace accumulates plenty of outdated pages — last year's project plan, concluded campaigns, documents that are no longer maintained. Deleting them feels wasteful; keeping them hurts search results and the accuracy of AI answers.

Notion launched the Archive feature in March this year to address exactly that.

You can mark outdated pages as archived. Archived pages show a banner at the top indicating who archived them and when. Archived pages do not appear in search results, the sidebar, or database views by default, but you can always filter them back into view.

The difference between archive and delete: archive just hides the page from search — the page itself is intact, all links and references still work, and unarchiving restores it instantly. Archiving a parent page automatically archives all its sub-pages.

For teams, regularly archiving outdated content dramatically improves search quality and AI answer quality, because the AI skips archived pages when retrieving workspace content, reducing the chance of being misled by stale information.

AI Voice Meetings

Notion launched AI Voice Notes in 2025, which can automatically record meetings and generate a transcript.

Seconds after the meeting ends, AI produces a structured summary — discussion highlights, action items, follow-up todos — saved directly as a Notion page. In early 2026 the feature expanded to mobile, meaning you can attend a meeting without a laptop and still record and transcribe on your phone.

So after every meeting, AI automatically transcribes the full discussion and extracts structured, important information. Team members can review it any time, and action items can be pulled directly from the summary and assigned to the right owner.

Agent Collaboration

Notion's current Agent capability is well beyond "help me write a sentence". I've written a series of long articles on this; if you're interested, check out these two (in Chinese):

• Getting started with Notion Agents
• 7 practical uses of Notion Custom Agents

In a team context, Agents can genuinely save a lot of time. A few concrete examples:

• When someone submits a request, auto-categorize it and assign it to the right owner
• When someone writes a doc, auto-generate a summary for other members to search
• When a task status changes, auto-notify downstream collaborators to take over
• When a client emails in, auto-create a project and break it down into tasks for the team
• On a schedule, roll up progress from multiple databases into a briefing for managers
• Before meetings, auto-prepare context so participants can dive right into discussion
• Chain automation pipelines together across roles
• Auto-answer customer questions from the knowledge base, covering for new hires

The core value of these capabilities is that they automate the "everyone knows this should be done, but no one wants to spend time on it" housekeeping work. For a team of five to ten, that can save at least an hour a day of small operations.

That said, these automations still require a certain setup threshold. You need to know how to design database structures, write Agent instructions, and set triggers — it's not out-of-the-box. So it's better suited to teams where someone is willing to spend time going deep on Notion.

Overall Assessment

My biggest takeaway from this round of testing: when it comes to collaboration permissions, Notion has finally crossed the line from "usable" to genuinely capable. From single-page sharing, to "Can edit content" and the "Read-only + Can create" combination, to person-field-based automatic page-level permission assignment, the whole logic now covers the vast majority of collaboration scenarios for a small-to-mid team.

When a tool reaches this level at the infrastructure layer, you naturally have more confidence in its ceiling — and more willingness to invest time exploring other possibilities.

Of course, permissions are just the foundation. Whether a team actually stays in Notion ultimately depends on whether day-to-day collaboration keeps up. As things stand, co-editing, comments, and suggested edits are more than enough to support async collaboration, and AI Agents can take over a lot of repetitive work on top. But the absence of instant messaging means Notion can't be the sole hub for team collaboration — it's better suited as the hub for knowledge and process, not communication.

After all, even Notion itself uses Slack alongside Notion.

How Chinese Teams Should Choose

Differences vs. Domestic Chinese Tools

If you are considering Notion, you are probably also considering Feishu or DingTalk. Each of these tools has its own strengths. Since I don't know the others inside out, I can only compare them from the angles I can clearly see.

1. Software ecosystem

Notion is clearly a product built for a global audience, so the software ecosystem that integrates with it does not really include Chinese-made tools. But for the same reason, if your work is tightly bound to Figma, GitHub, Linear, or the Google ecosystem, Notion's integrations will be the best.

And as one of Anthropic's top ten Token consumers, Notion supports the latest AI models (Gemini, Claude, GPT) the fastest and best. So if your team values AI capability, Notion will have a clear edge over domestic Chinese collaboration tools.

2. Communication style

If your team is used to the IM-first style of Feishu or WeCom — sharing docs directly in group chats, converting discussion to tasks with one click, auto-pushing doc updates into a chat group — Notion can't do those today, because it has no official instant messaging tool. All communication has to happen inside Notion's own surface, or alongside a third-party IM (like Notion's own team does with Slack).

If your team runs mostly on async, with people working at their own pace, this limitation doesn't really matter.

3. Data security

Data security is an evergreen question for any cloud product — even Feishu and DingTalk aren't immune, and Notion, with servers outside China, is all the more exposed.

My take: for a fast-growing product like Notion, the chance of it simply disappearing overnight is basically zero. But any mature team should still treat data security with respect — regularly exporting full backups is the right move. Fortunately, Notion has long supported exporting the entire workspace to Markdown, PDF, or HTML, which is a rare and worthwhile feature.

How Short Are the Shortcomings

Before making a decision, there are a few more important questions to consider. Choosing this kind of tool isn't about how long its best side is — it's about whether you can live with its weakest side.

1. Not cheap

Notion's free tier is already very capable, but for serious collaboration you'll want at least the Plus plan, which is $120 per seat per year. To add AI features you need Business, at $240 per seat per year.

2. Migration cost

If your team already runs a mature collaboration workflow on Feishu, DingTalk, or another platform, moving to Notion will cost more than you expect. Adaptation, training, and collaboration disruptions all need to be planned for in advance.

Also, Notion's mental model is fairly different from mainstream Chinese tools. If team members aren't clear on how to create a doc or what a database is, the early learning curve will be steep. So if you're pushing this change, make sure the person driving it is both the most Notion-savvy and has enough decision-making power to move past resistance.

3. Access difficulty

Your team needs to be willing to navigate some minor hurdles around network stability and payment convenience in exchange for the best AI and Agent capabilities. I won't go into detail here.

What Kind of Team Is This For

Choosing Notion as your collaboration tool and knowledge hub shouldn't be a gut decision, and shouldn't be driven by surface-level or flashy features. Migrating personal notes is already painful; migrating team docs is orders of magnitude harder.

In my view, only teams that fit all three of these profiles should seriously consider Notion:

1. Teams that want to raise their workflow ceiling

Willing to invest time in building a knowledge base, refining collaboration processes, and deeply integrating AI Agents into daily work — and whose members already have basic Notion experience. Under those conditions, the return from Notion is very high.

2. Teams whose core output is knowledge-intensive work

Content creation, product design, consulting, research. Their daily output is documents, proposals, knowledge bases — and Notion can tie these scattered pieces together and let information flow across the team instead of getting buried in individual folders.

3. Teams that see their workspace as a long-term asset

Notion compounds over time. Database structures, permission rules, Agent workflows — the longer you use them and the more you accumulate, the more the efficiency gains compound. The reason I'm willing to spend several days writing this article is honestly because I believe Notion is genuinely great for knowledge workers.

It is unlike any other doc or knowledge-base product in that the ceiling it offers is the highest. The most cutting-edge AI companies today, such as OpenAI and Anthropic, use Notion internally — which also validates the point that in teams with the highest knowledge density, Notion's collaboration holds up.

That's everything I learned and recommend from this round of testing. Every team is different and so is the right tool. All I can do is write down what I've actually tested as clearly as possible, but there are certainly angles and scenarios I couldn't cover. So if you run into any specific issues in real use, feel free to leave a comment below — I'll keep answering them.