# 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](https://www.youtube.com/watch?v=tJGuxqhv2SY&t=12s) we set up our instance, and in [part two](https://www.youtube.com/watch?v=7SNrBzaxreg&t=108s) 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

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