Directus Basics Part 3 — User Roles & Permissions

https://www.youtube.com/watch?v=qAk3X4y8v1U

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.

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

1. Go to Settings → Access Policies → Public

2. Under Permissions, click Add Collection

3. Select products

4. Click Read, choose All Access

5. Save

Creating a Custom Access Policy

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

1. Go to Access Policies, click Create

2. Name it DataEntry

3. Check App Access — leave Admin Access unchecked, since that grants unrestricted control

4. Save

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

Add products to it:

1. Click Add Collection, select products

2. Click Read, choose All Access

3. Save

Creating the User Role

1. Go to User Roles, click Create

2. Name it DataEntry

3. Under Policies, click Add Existing, select the DataEntry policy

4. Save

Creating the User

1. Go to User Directory, click Create

2. Fill in first name, last name, email, and password

3. Under Role, select DataEntry

4. 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.

1. Click Add Collection, select directus_files

2. Click Read, choose All Access

3. Save

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

Adding the Thumbnail to List View

1. In list view, click the + icon on the right

2. 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

3. Scroll to thumbnail, click outside the dropdown to confirm

Drag column headers to reorder them as needed.

Extending Access to Related Collections

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:

1. On the products collection, click the Update action

2. Choose Use Custom

3. Click Field Permissions

4. Check Name

5. Save, then save again

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

Summary

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.