As a team grows, it is easy to assign permissions by title or convenience: managers become admins, practitioners become editors, and external collaborators become viewers. But people with the same title may work in different folders and need different actions. Someone with a more junior title may still need editing access when they own a document update.
Permissions are not an org chart. They are an operating matrix that defines which actions are allowed in each folder, who is responsible for their consequences, and who approves exceptions.
List required actions before permission names
Before inviting a new member, write the work they need to do as verbs:
- Open and review documents
- Copy and share an existing link
- Upload a new version
- Change link-specific sharing settings
- Move or delete documents and folders
- Invite another team member to a folder
- Manage members and settings across the space
Keep only the actions actually required. Instead of granting edit or admin access because it might be useful later, review the role again when responsibility expands.
Distinguish viewer, editor, and admin scope
FeatPaper access permissions are divided into viewer, editor, and admin roles. Viewers and editors are assigned at the folder level; admins are assigned across the space.
A viewer can open documents in a folder and copy existing general-sharing and information-input links. A viewer cannot create a new recipient-specific tracking link, view or copy an AI public link, change link settings, or upload a new version.
An editor can upload and modify documents, upload new versions, create recipient-specific tracking links, change per-link sharing settings, and invite or manage people within the folder. A folder owner and an editor have the same product permission scope for that folder.
An admin manages space-wide members and admin-only settings. Not every document operator needs to be an admin. Separate folder editing responsibility from space administration so admin access does not spread as a convenience for daily work.
Include responsibility and exception approval in the role matrix
A permission table should contain more than names:
| Working role | Allowed actions | Folder scope | Prohibited actions | Responsible owner | Exception approver |
|---|---|---|---|---|---|
| Distribution operator | View documents, copy existing links | Approved materials | Change settings, delete | Campaign owner | Folder owner |
| Content operator | Upload versions, change link settings | Operating materials | Space administration | Content owner | Admin |
| Space admin | Manage members and admin settings | Entire space | Approve content on another owner’s behalf | Operations lead | Organization owner |
Product permissions and organizational approval authority are not the same. Having an editing capability does not grant authority to approve every piece of content. Record system permissions and business approval separately.
Treat folder inheritance and document moves as access changes
In FeatPaper, documents follow the permissions of their folder. Subfolders inherit parent-folder permissions, and inviting someone separately to a subfolder adds permission within that scope. When a document moves, the destination folder’s permissions apply.
A document move is therefore more than housekeeping. Before moving it, check:
- Who can access it in the current folder?
- Who can view or edit it in the destination folder?
- Does the responsible owner change after the move?
- Do externally distributed links require separate review?
Do not assume that changing folder sharing or moving a document changes external link conditions in the same way.
Keep internal folder permissions separate from external link settings
Folder permissions define which workspace members can find, view, and edit documents in the dashboard. Link-specific sharing settings define conditions for external visitors who enter through that link. These axes do not inherit from one another.
Removing an internal viewer from a folder does not by itself prove that an already distributed external link has closed. Changing one link’s access conditions does not change a team member’s folder permission. Review internal responsibility changes and external distribution paths through separate checklists.
This separation does not guarantee security. Confirm who can access the material through each current path and apply the organization’s policies.
Record exceptions by reason and review condition, not only by person
An urgent project or temporary support assignment may require broader permission than usual. If the exception is recorded only as “Editor this time,” the reason becomes difficult to recover later.
Record the required action, folder scope, approver, start date, and review condition. Do not assume the system will revoke it automatically; verify current permission at the agreed time.
A periodic review does not have to begin with every member. Start with recently moved documents, folders with a changed owner, exception permissions, and areas with many external links.
Check the minimum matrix before inviting someone
- Required actions are written as verbs.
- Folder editing and space administration are separated.
- Folder scope and inheritance are understood.
- Document moves are reviewed as possible access changes.
- Internal folder permissions and external link settings are checked separately.
- Exceptions include a reason, approver, and review condition.
- System capability is not confused with content approval authority.
A good permission design is not a document that merely repeats “least privilege.” It is a matrix that lets the right person perform the required action in the right folder while making responsibility for results and exceptions clear. Assigning viewers, editors, and admins by action and responsibility lets permissions follow how the team actually works.
