Access control in a digital asset management platform answers two separate questions. The first is what someone is allowed to do — upload, download, edit metadata, share, delete. The second is which assets those abilities apply to. Keeping these apart is what makes a permission structure comprehensible a year after it was built, and conflating them is why so many of them become unmanageable.
Rather than a single setting per user, access is assembled from layers that each narrow what the previous one allowed:
A user sees an asset only when every applicable layer permits it. The layers are cumulative restrictions, not competing settings, which means troubleshooting is a matter of working down the list until you find the one saying no.
There are two kinds of role, and the distinction matters more than any other in the system.
Application roles govern access to record types such as assets, accounts and portals, to components such as public links or the location map, and to administrative areas including metadata structure, user management, branding and reports. Folder roles govern access to particular folders and the assets inside them.
An application role decides whether someone can create portals at all; a folder role decides which assets they can put in one. Because the two are separate, the same capability can be granted in one part of the library and withheld in another without duplicating anything.
Roles that grant nothing are not merely inert — the interface adapts to them. If a role does not grant access to a record or component, it does not appear for that user. People are not shown buttons that will refuse them, which is worth remembering when someone reports that a feature is "missing" rather than blocked.
Roles are not assigned to people directly. They are collected into user groups, and users are assigned to groups. A group can hold several roles, both application and folder, and a user can belong to several groups.
That combination is the point. Rather than building one exhaustive group per job title, most organisations do better with a baseline group everyone belongs to, a small number of functional groups covering what people do, and a set of groups establishing boundaries around departments or projects. Someone's access is then the sum of two or three group memberships, and a new starter is set up by choosing from an existing vocabulary instead of inventing another group.
Our guide to planning a permissions strategy works through this in depth, including how many groups to aim for and the mistakes that make a structure collapse under its own weight.
Folder permissions work when access requirements line up with how content is organised. Often they do not. A single campaign folder can hold approved material for everyone alongside drafts that only the design team should see, and splitting it into two folders solves the access problem by making the library harder to navigate.
Visibility levels handle that case. Each level has a tier number, and users see assets at or below the tier assigned to their group, so a user at tier 3 sees tiers 1 through 3 and nothing above. The check runs in addition to folder permissions rather than instead of them: someone needs both folder access and a sufficient tier before an asset appears. Assets with no level assigned fall to the lowest tier, so enabling the feature does not hide existing content.
This is the layer to use for work in progress, management-only material, or an agency that should reach most of a folder but not all of it. About Visibility Levels covers the setup in detail.
Occasionally the sensitive part of an asset is not the file but something recorded about it — a licence cost, an internal note, a contract reference. Metadata permissions on user groups narrow access at field level, and fields can be hidden from particular groups entirely, so a person can work with an asset without seeing everything attached to it.
These controls are optional and enabled per workspace. They are worth reaching for when specific fields are genuinely confidential, and worth avoiding when the goal is merely tidiness, since a metadata profile already determines which fields appear in a given context.
The most common permissions mistake is creating accounts for people outside the organisation. Every account is a permission structure to maintain, review and eventually remove, and clients, agencies and partners rarely need one.
Portals and public links exist for this. They deliver selected assets to external recipients with their own access rules and expiry dates, and they leave your internal permission model untouched. Create real accounts for external people only when they genuinely need to work inside the platform.
Administrators hold full platform access, and rights reach a user by two independent paths: granted directly on the user, or inherited from membership of a group marked as an admin group. The two are tracked separately, which produces a result worth knowing before it surprises you — remove direct admin rights from someone who is also in an admin group and they remain an administrator through the group until removed from that as well.
Only administrators can create or edit other administrators, mark a group as an admin group, or reset an administrator's password. Keep the number small; full access is rarely what anyone actually needs, and it removes the accountability that the rest of the structure provides.
Permission structures are difficult to verify by reading them, because the question is never "which roles does this person have" but "what happens when they open the library". An administrator can log in as another user from that user's profile and see the platform exactly as they experience it, with a banner showing the session and a way back to their own account.
This is the fastest answer to any "why can't I see this?" report, and it is more reliable than reasoning through the layers. Use it before changing anything, and again afterwards to confirm the change did what you intended.