Skip to content
Onplana Docs

Share a library or list (per-resource access)

All plans Member

Document folders and lists normally follow your role: anyone who can open the workspace can open the folder. Per-resource sharing lets you lock a single library or list down to specific people and teams instead, and the same control works the same way in two places:

  • inside any project’s Workspace (the Workspace tab on a project), and
  • inside the organization Workspace at /workspace.

It applies to both document libraries and lists (tables).

Restrict a library or list

Section titled “Restrict a library or list”

  1. Open the library or list and select Manage access from the … (more actions) menu in its header. You will see it if you are the resource’s creator, an organization Owner / Admin / Portfolio Manager, or (for a project resource) the project’s Owner or Manager.

  2. Turn on Restrict access. The resource now follows explicit grants only. A small Restricted badge appears next to its name so everyone can see at a glance that access is limited.

  3. Under Share with, choose a Person or a Team, pick an access level, and select Add.

  4. Change a grantee’s level inline at any time, or remove them.

Access levels

Section titled “Access levels”
LevelWhat it allows
Can viewOpen the library or list and read its contents. A view grantee cannot edit, upload, create, share externally, or open the Office editor in edit mode.
Can contributeView, plus add and edit documents, rows, and metadata, create files, and share documents externally.
Can manageContribute, plus manage sharing (restrict, add and remove grants) for this resource.

Sharing with someone outside the project

Section titled “Sharing with someone outside the project”

A restricted project resource can only be shared with members of that project. To share with someone who is not on the project yet:

  1. Add them to the project first, an outside collaborator can be added as a guest (the project-only Guest role).

  2. Then grant them access to the library or list from Manage access.

This keeps project content inside the project’s membership. Organization Workspace resources have no project boundary, so you can share them with any person or team in the organization.

Who can always get in

Section titled “Who can always get in”

Restricting a resource never locks out the people responsible for it, but who that is depends on the resource’s scope.

On an organization Workspace resource, organization Owners and Admins, and the resource’s creator, always keep full access.

On a restricted project resource, only the creator and the project’s Owner and Manager keep full access. Organization Owners and Admins who are not on the project keep read-only oversight, and org-level admins can still manage sharing, so an org admin who is already on the project can grant themselves access (one who is not on the project has to be added to it first, because a grant can only go to a project member). An org admin who is only a plain project member has no access until they are granted it.

If you restrict a resource you would otherwise lose manage rights to, Onplana automatically grants you Can manage so you do not lock yourself out.

Section titled “External share links honor restrictions”

If you share a document externally with an email-gated link, that link respects per-resource sharing:

  • You need Can contribute (or higher) on the library to create a share link.
  • Restricting a library, or removing the link creator’s access, revokes the library’s active external links so they stop working.

FAQs

Section titled “FAQs”

Can a view-only grantee re-share the library with someone else? No. Generating an external email-gated link requires contribute access or higher; viewers cannot create share links. This stops a single view grant from leaking the library outside your organization.

Who can rename or delete a restricted library? Manage access. On a project resource, that is the library’s creator, the project’s Owner or Manager, and anyone with an explicit manage grant. Organization-level admins (org.project.view.all) can always manage sharing on a restricted project resource without a grant, but that lets them restrict, add, and remove grants, not rename, move, or delete the library itself; renaming or deleting still needs a manage grant like everyone else. Project members with only contribute or view access can read and edit content but cannot manage the library itself.

What happens to the grants if the library is moved to the Recycle Bin? Grants are snapshotted into the recycle bin entry. Restoring the library re-creates them under the new id automatically; you do not have to re-share with everyone after a restore.

Can I share a project library with an organization member who is not on the project? Add them to the project first as a guest (the project-only role), then grant them the library access level you want. The members-only boundary applies: a person who is not on the project cannot receive a grant on its libraries, even at the organization-admin tier.

What happens to live external share links when I restrict a library? The restriction event automatically revokes any active external share links the library had. New share links can only be created by users with contribute access or higher under the new restriction policy.

Best practices

Section titled “Best practices”
  1. Restrict only what genuinely needs it. Default-shared libraries support collaboration; restricted libraries support confidentiality. Use restriction for HR, contracts, legal, not every project file.
  2. Use Teams instead of individual user grants when possible. Team grants auto-update as people join/leave teams. Per-user grants become stale.
  3. Default to “Can view”. Most grantees don’t need to edit. Start view-only; upgrade to contribute when a specific need arises.
  4. Always keep one “Can manage” grantee besides yourself. A single manage grantee = single point of failure. If you leave, the resource is harder to manage. Add a co-manager.
  5. Explain the boundary the way it works. Cross-project sharing happens via the Guest role on the receiving project, that’s the design, not a limitation.

Troubleshooting / common pitfalls

Section titled “Troubleshooting / common pitfalls”
  • Manage access option missing. You’re not in the manager list for this resource. Need creator, project Owner/Manager, or organization Owner/Admin to see it.
  • Can’t add a grantee. Two causes: (a) for project resources, grantee isn’t on the project, add as Guest first; (b) for organization resources, grantee isn’t an organization member.
  • Restricted library still visible to someone. They may be an organization Owner or Admin (full access on an organization resource, read-only oversight on a project one), the creator, or hold an explicit person or team grant.
  • External share link stopped working unexpectedly. Library was restricted or a grant was removed. Recreate with contribute-access user.
  • Manage access missing from the menu. Manage access lives in the row’s overflow menu. If it’s missing, check your role and membership.

How this combines with other features

Section titled “How this combines with other features”

Coming from another tool

Section titled “Coming from another tool”
ToolMapping
SharePoint permissionsDirect concept; folder-level restrict + grant
Google Drive sharingDirect
OneDrive item permissionsDirect
Confluence space permissionsDirect
Custom RBACOnplana uses standard grant model
Section titled “Related”