I am designing a permission model for using SeaTable in an enterprise environment and would like to confirm whether the following access pattern is supported.
Intended Setup
Create one group called: PROJECTS
Add all employees (e.g. ~100 users) to this group, so everyone can see said Groups (PROJECTS)
Inside this group, create project‑specific bases, for example: PRJ_0001; PRJ_0002; so on
Required Access Behavior
All users are members of the group PROJECTS
Only authorized project members should be able to access a specific base (e.g. only PRJ_0001 team members can open PRJ_0001)
Other group members should not be able to open or view the data of that base
Question
Is it possible in SeaTable to:
Restrict access at base level for users who are already members of the same group?
In other words, can a base inside a group be made accessible only to a subset of group members?
If this is not supported, could you please confirm:
Whether the recommended / only supported approach is to create separate groups per project (one group = one project)?
Or if there are any enterprise / advanced permission features that enable this scenario?
Any official guidance or best‑practice recommendation would be very helpful.
Good question! This comes up regularly in enterprise setups. Let me try to clarify this.
Short answer: No, this is not how groups work in SeaTable.
When you add users to a group, all group members can access all bases in that group. There is no way to restrict access to individual bases within a group to a subset of members.
The recommended approach is: one group per project.
So instead of one large “PROJECTS” group, you would create:
Group PRJ_0001 → with only the project members of PRJ_0001
Group PRJ_0002 → with only the project members of PRJ_0002
and so on
This way, each base is only accessible to the users in its respective group. This is the standard and intended permission model in SeaTable.
What about cross-project visibility?
If certain users (e.g. management or PMO) need read access across all projects, you can share individual bases to them via the Share to user feature — either with read-only or read-write permission. This works independently of group membership.
Summary
One group, restrict bases to subsets of members → not supported
One group per project → recommended approach
Cross-project access via base sharing → supported
This scales well even with many projects. Group creation and membership can also be managed via the List Groups if you want to automate onboarding.
