A grant does not replace normal account, organization or asset-type authorization. A user still needs the relevant scope and read permissions. An asset-type deny can prevent access even when a matching grant exists.

Admin does not automatically mean access to every record. Ordinary Admin users do not bypass record grants. System roles with grant-bypass permission are separate from your account's Admin role.

Record owners have an access path through ownership, subject to the surrounding authorization checks.

Folders are a view of tags. They do not have a second, independent permission system.

A record is subject to tag restrictions when an assigned tag—or any ancestor of that tag—is restricted.

Grants on a parent apply down the tree. Child folders can add people or groups, but cannot remove access inherited from a parent. There is no “break inheritance” setting.

A grant on a child does not give access to records tagged only with its parent.

Yes, for non-private records tagged with that folder or one of its descendants, provided the user also has the required account, organization and asset-type access. Parent grants apply down the tag hierarchy; the record does not need the parent tag directly assigned as well.

Browsing a folder is not itself a grant. Private records and records outside the user's permitted scope remain inaccessible. A child-folder grant does not extend upward to records tagged only with its parent.

For a non-private record, a matching grant through any one assigned tag or its ancestors can provide access. Users do not need matching grants on every assigned tag.

Adding an unrestricted tag does not cancel a restriction imposed by another tag.

A record set to restricted can also be accessible through an explicit record grant. Its explicit grants and applicable tag grants are alternative access paths.

The table below explains the record-grant layer; account, organization and asset-type checks still apply.

This explains existing access states; it does not imply every state is selectable in every screen.

Consider this folder structure:

Assuming normal scope, read permission and non-private records:

Making Finance restricted does not exclude Alice. Her Operations grant still applies.

A document tagged with both Finance and Networking can be visible to either Alice or Bob through their applicable grants.

Admin and Support users have permission to manage individual record grants, subject to access checks. Admin users can also manage tag grants and the tag hierarchy. Support users cannot administer tag grants.

Admin and Support users can assign tags to records they can edit. Filing into or out of a restricted folder requires record-access management permission as well.

Grant-management permission is a capability to change access; it is not a general bypass for reading every restricted record.

The owner retains an ownership access path. Removing a grant that provides your access can remove your ability to see the record if no other access path remains. Record access changes are separate from Save changes for document content.

When a parent is restricted, the options distinguish Use inherited access grants only from Add additional access grants. The latter adds access; it does not replace the parent's grantees.

A restricted tag stays restricted when its last grant is removed. Deleting a granted user or group does not make its records open.

Records may still be accessible through ownership, a bypass role, another assigned tag, or a valid explicit record grant. “No grants on this tag” does not by itself describe every access path to a record.

The tag-access editor requires at least one grantee when applying its restricted option. Empty restrictions can nevertheless arise through other supported changes, such as removal of a granted user or group.

An administrator can restore appropriate tag access by adding a valid person or group or explicitly removing the tag's own restriction. Removing a child's own restriction does not remove a parent's restriction.

Removing a parent's restriction also removes that parent's grants. Check any still-restricted descendants that relied on those grants.

Check these paths before assuming the restriction failed:

For missing access, also check organization scope, asset-type denies and private visibility. Folder names and hierarchy should not be treated as secret merely because the records inside are restricted.