In Lark Base advanced permissions, a role is simply a permission group: you decide what the role can see and edit, then drop people into it.
What trips teams up is that there are two kinds of role with different rules, they interact with the ordinary sharing panel, and someone can end up in more than one at once.
This explains how they differ and which permission wins when they collide.
Note: Only the base owner and administrators can assign roles in advanced permissions.
The Two Kinds of Role
Once advanced permissions are on, the left-hand panel splits into System roles and Custom.
System roles are fixed. You cannot add, rename or delete them, and two of the four cannot even have their permissions changed. Custom roles are yours to shape entirely.
The Four System Roles
1. Owner
The person who owns the base. Manage permission on every table, edit permission on dashboards, and none of it can be modified. You cannot add or remove members from this role.
2. Administrator
Identical permission level to the owner, and equally unmodifiable, but you can add and remove members. Anyone given manage permission in the collaborator panel lands here automatically.
3. Editor
The first role you can actually configure. Table permissions can be set to Can manage, Can edit, View only or No access, and you can refine record, field and view access underneath.
Dashboards are more restricted: Editor can only be given View only or No access.
Anyone granted edit permission in the collaborator panel joins this role automatically.
4. Viewer
The most limited system role. Table permissions offer only View only or No access, though you can still narrow which records, fields and views are visible within that.
Dashboards follow the same two options.
Anyone granted view permission in the collaborator panel joins this role automatically.
Moving someone between Editor and Viewer
Click the role, then the profile photo section on the right to open Members assigned to this role. Click the Switch to another system role icon beside a member and pick the other role.
Custom Roles
Custom roles are permission groups you define from scratch, and they can be added, renamed and deleted freely. Click Add Role to create one, configure its permissions, then add members. Hovering over a custom role and clicking the ··· icon gives you rename, duplicate and delete.
Duplicating a role
Click the ··· icon next to a custom role and choose Duplicate. This copies the permission settings for tables, dashboards and other features, but not the people.
Note: Duplication only carries permissions for tables and dashboards that currently exist. If a deleted table is later restored, the duplicated role will have no permissions for it.
Copying permissions for a single table
Sometimes you only want to replicate one table’s settings. In a custom role’s data permission list, hover to the right of a table or dashboard, click the Copy permissions icon, choose the target role from the dropdown or search bar, then click Confirm.
Moving someone between custom roles
Open the role’s Members assigned to this role page, click the Change to other custom roles icon beside a member, and select the destination.
Important: This shortcut works between custom roles only. You cannot use it to move someone from a custom role into a system role, or the other way around.
The Two Access Modes
At the top of the advanced permissions panel sits a setting that changes who can reach the base at all.
- Grant Access Through Sharing: The default, and the sensible choice for data that is broadly shareable. People can be added through the sharing panel or a share link and will receive manage, edit or view permissions accordingly.
- Only Custom Roles Can Access: The choice for sensitive data. Only members of custom roles, plus anyone with manage permission, can open the base. Share links stop working, and collaborators given view or edit permission through the sharing panel are locked out.
Important: Switching to Only Custom Roles Can Access disables the Editor and Viewer roles entirely. Owner and Administrator are unaffected. If you have people relying on Editor or Viewer access, move them into a custom role first.
How Roles Connect to the Collaborator Panel
The collaborator panel is what opens when you click Share in the upper-right corner of the base and then the profile photo section beside Invite Collaborators.
The two systems stay in step automatically:
- Anyone added to a system or custom role becomes a document collaborator.
- Anyone given manage permission in the collaborator panel joins the Administrator role.
- Anyone given edit permission joins the Editor role.
- Anyone given view permission joins the Viewer role.
- Remove someone from the collaborator panel and their advanced permission role becomes invalid, so they lose access entirely.
Note: If the base contains sub-pages, adding or removing members from system roles affects collaborators on the current page only.
Which Permission Wins
This is where most confusion starts, because one person can sit in several roles at once. Lark resolves it with a fixed hierarchy.
Between roles
- Owner and Administrator beat everything. Someone in the Administrator role and a custom role gets administrator permissions.
- Custom roles beat Editor and Viewer. Someone in both Editor and a custom role gets the custom role’s permissions.
- Editor beats Viewer. Someone in both gets editor permissions.
A member of a custom role can also be added to Administrator, but never to Editor or Viewer.
Between the collaborator panel and advanced permissions
Outside of manage and administrator level, the lower of the two applies. A person only gets permissions that exist in both places.
Take a worked example. Alice is set to Can view in the collaborator panel, then added to a custom role that grants edit and view rights on certain records. Alice ends up with view permission only, and the records she can see are still limited by her custom role.
The exception is manage level. Set someone to Can manage in the collaborator panel and add them to a restrictive custom role, and they keep manage permission regardless. The same applies to the Administrator role.
Practical Use Cases for SMEs and Startups
- Client-facing base: Switch to Only Custom Roles Can Access so a stray share link cannot expose anything.
- Departmental variants: Build one role properly, then duplicate it and adjust rather than starting over for each team.
- New table rollout: Use Copy permissions to push one table’s settings across several roles in a few clicks.
- Promotions and moves: Switch someone from Viewer to Editor from the member list instead of unpicking the sharing panel.
- Auditing access: Check the collaborator panel and the role list together, since the stricter of the two is what actually applies.
Frequently Asked Questions (FAQ)
What is the difference between system roles and custom roles in Lark Base?
System roles are the four built-in roles (owner, administrator, editor and viewer) that cannot be added, renamed or deleted. Custom roles are permission groups you create, configure and remove as you like.
Which permission applies if someone is in two roles?
Owner and administrator override everything. Custom roles override editor and viewer. Editor overrides viewer. So a person in both a custom role and the editor role gets the custom role’s permissions.
Why can’t a user access the base even though they are a collaborator?
The base is probably set to Only Custom Roles Can Access, which disables the editor and viewer roles. Collaborators given view or edit permission cannot get in unless they are also in a custom role.
Do I need to add people twice, once as a collaborator and once to a role?
No. Adding someone to a role makes them a collaborator, and adding a collaborator places them in the matching system role based on the permission you grant.
Can I move a member from a custom role to a system role?
Not with the switch shortcut, which works only within system roles or within custom roles. You would need to remove them from one and add them to the other.
Does duplicating a custom role copy its members?
No. Duplication copies permission settings for existing tables, dashboards and other features, but the new role starts with nobody in it.
What happened to the default role from the older permissions system?
It has been replaced by system roles. On upgrading, a default role that could access the base becomes a custom role with the same name, permissions and members. A default role without access has its members moved to the viewer role, with no access to the base.
Getting the Role Structure Right
Most permission problems in Lark Base are not misconfigured settings but overlapping roles: someone sitting in a system role and a custom role, or a collaborator permission quietly capping what their role allows.
Decide your access mode first, build custom roles for anything sensitive, and remember that outside of manage level, the stricter of the two systems always wins.
Ready to Power Your Business with Lark?
Lark Base is just one part of an all-in-one platform that brings messaging, meetings, documents, approvals, and automations together for your entire team.
As the Platinum Partner for Lark in Malaysia, Exabytes offers tailored Lark plans, hands-on onboarding, and dedicated local support to help your team structure access properly from the start.
