Directus Basics Part 3 — User Roles & Permissions

Fri, 21 Aug 2026 06:23:23 +0000

This is part three of our Directus Basics series. In part one we set up our instance, and in part two we covered relationships between collections. Today we're covering access control — what determines who can see and touch your data.

Part III - Youtube

The Core Concepts

Access control in Directus comes down to three terms:

Permission — applies to one collection and one action (create, read, update, delete, or share). Can be full access, no access, or custom rules.
Policy — a group of permissions bundled together, applied to users or roles.
Role — defines a user's position within a project. A role can hold any number of policies, apply to any number of users, and have child roles of its own.

What Happens Without a Role?

If an administrator creates a user but doesn't assign a role, that user has valid login credentials but still can't access the Data Studio.

Creating a role and assigning the user to it isn't enough either — logging in at that point returns a "No App Access" error. The missing piece is that the role has no access policy attached. The policy is what actually tells the role what its users can and can't do.

The Access Order

Access in Directus flows in a specific direction:

Access Policy → Role → User

In practice: define what level of access a user needs, build an access policy to match, create a role and attach that policy to it, then register the user and assign them to the role.

Default Policies

Every fresh Directus instance ships with two default policies:

Administrator — the role you're signed in as by default, with unrestricted access to everything.
Public — for data that should be visible without logging in. Think of a product catalog on an e-commerce site — forcing a login just to browse products is a poor experience.

Rule of thumb: give the Public policy Read access only. Never Create, Update, or Delete. The public should be able to view data, never manipulate it.

Giving a Collection Public Access

Go to Settings → Access Policies → Public
Under Permissions, click Add Collection
Select products
Click Read, choose All Access
Save

Creating a Custom Access Policy

Let's build a policy for a data-entry team member with limited access.

Go to Access Policies, click Create
Name it DataEntry
Check App Access — leave Admin Access unchecked, since that grants unrestricted control
Save

Directus populates the policy with minimum defaults for its own system collections, but nothing for your custom collections yet.

Add products to it:

Click Add Collection, select products
Click Read, choose All Access
Save

Creating the User Role

Go to User Roles, click Create
Name it DataEntry
Under Policies, click Add Existing, select the DataEntry policy
Save

Creating the User

Go to User Directory, click Create
Fill in first name, last name, email, and password
Under Role, select DataEntry
Save

If you check back on User Roles, you'll see a 1 next to DataEntry under Users, and a matching 1 under Access Policies. That confirms the role, policy, and user are all wired together correctly.

Tip: giving your policy and role the same name (as done here with "DataEntry") makes them much easier to track as your project grows.

Testing Read-Only Access

Log in as the new user. You'll see the products collection, but attempting to edit any field does nothing — expected, since only Read access was granted.

Scrolling to the bottom of a product's detail page, some data is simply missing — those fields belong to other collections the user doesn't yet have permission for. The product image is missing too.

Fixing the Missing File Permission

Back in the DataEntry policy, notice directus_files isn't included among the accessible system collections. Without it, uploaded files — including product images — stay invisible.

Click Add Collection, select directus_files
Click Read, choose All Access
Save

Log back in as the data-entry user, and the product image now appears.

Adding the Thumbnail to List View

In list view, click the + icon on the right
Scroll to image, click the arrow next to it — not the field name itself, or you'll add the raw file ID instead of the thumbnail
Scroll to thumbnail, click outside the dropdown to confirm

Drag column headers to reorder them as needed.

The same missing-permission pattern applies to branding, products_tags and tags — add all to the DataEntry policy with Read access, and the relational fields on products become visible.

Key takeaway: you can't access a relational field in one collection unless you also have permission on the related collection. Both sides of the relationship need coverage.

Custom Field-Level Permissions

Sometimes all-or-nothing collection access isn't granular enough. Directus lets you restrict access down to individual fields.

Let's allow the data-entry user to update only the name field on products:

On the products collection, click the Update action
Choose Use Custom
Click Field Permissions
Check Name
Save, then save again

Logging back in, the data-entry user can now edit the Name field — and nothing else on that collection.

Summary

Concept	Definition
Permission	One collection + one action, set to full/none/custom
Policy	A bundle of permissions, applied to users or roles
Role	A user's position in the project; holds policies, applies to users

Access control in Directus is genuinely one of its most powerful features — this covers the fundamentals, but there's plenty more granularity available as your project grows.

That wraps part three. Next up, we'll look at how everything from this series comes together once we start pulling this data into a real front end.

Found this useful? Follow for more Directus and TanStack Start tutorials, or check out the video version above.

Coder Legion - Recent posts tagged roles