Set Folder-Level RBAC Permissions in Grafana (2026)

Grafana’s folder-level RBAC is actually a layer on top of its existing team-based permissions, not a replacement, and it can be a bit confusing because it feels like you’re directly assigning permissions to users when you’re not.

Let’s see it in action. Imagine we have a dashboard we want to restrict.

First, you need to have the Grafana Enterprise license and RBAC enabled. You can check this in your Grafana configuration file (e.g., grafana.ini) under the [enterprise] section. Ensure rbac_enabled = true.

Now, let’s say we have a folder called "Finance" and we want only members of the "Finance Team" to be able to view dashboards within it.

Here’s the typical setup before folder-level RBAC: You’d go to Server Admin -> Teams and create a team named "Finance Team". Then, you’d go to Dashboards -> Folders, find the "Finance" folder, click the gear icon for settings, and under Permissions, you’d add the "Finance Team" with "Viewer" permissions.

This works, but it’s not granular enough if you have different user roles within the "Finance Team" that need different access levels to different folders.

Folder-level RBAC lets us define these permissions more precisely.

The Core Concept: Roles and Permissions

Instead of directly assigning permissions to a team on a folder, you define roles that have specific permissions on specific resources.

Define a Role: You’ll create a role that represents the kind of access you want. For example, a role named finance_viewer.
```
# Example using Grafana CLI (or API)
grafana-cli admin roles create finance_viewer --display-name "Finance Viewer"
```
Assign Permissions to the Role: Now, you grant the finance_viewer role the ability to view dashboards within the "Finance" folder.
```
# Example using Grafana CLI (or API)
grafana-cli admin roles permission add finance_viewer grafana:folder:read --scope "folder:Finance"
```
Here:
- grafana:folder:read is the specific permission action.
- --scope "folder:Finance" is the resource constraint – it only applies to the folder named "Finance".
Assign the Role to a Team (or User): Finally, you assign this finance_viewer role to your "Finance Team". This is where it connects back to your existing user/team structure.
```
# Example using Grafana CLI (or API)
grafana-cli admin roles assign finance_viewer "Finance Team"
```
Now, any user who is a member of the "Finance Team" will inherit the finance_viewer role, and thus the grafana:folder:read permission on the "Finance" folder.

Why is this powerful?

You can now have multiple roles for the same folder. For instance, you could create a finance_editor role with grafana:folder:write permission on the "Finance" folder and assign it to a different team or a subset of users within the "Finance Team" (though typically you’d manage subsets via different teams).

You can also apply this to other resources, like dashboards themselves (grafana:dashboard:read, grafana:dashboard:write) or even specific data sources.

The Mental Model:

Think of it as a three-tier system:

Users belong to Teams.
Roles are defined with specific Permissions on Resources.
Teams (or individual users in more advanced setups) are assigned Roles.

When a user tries to access a resource (like a dashboard in the "Finance" folder), Grafana checks:

Does this user have a role assigned directly to them that grants permission?
If not, do any of the teams this user belongs to have a role assigned that grants permission?
If so, does that role’s permission on that resource (with the correct scope) allow the requested action?

The Counterintuitive Part

Many people expect to see a direct "Assign Permissions to Folder" button that lets them pick users or teams and then choose "Viewer", "Editor", etc., similar to how dashboard permissions worked historically. Instead, folder-level RBAC uses a more abstract system of roles, permissions, and scopes. You’re not assigning directly to the folder; you’re assigning a role to a team, where that role itself has been granted a specific permission on that folder. This indirection is key to its flexibility but also its initial confusion.

The next step is understanding how to define custom scopes beyond just the folder name, allowing you to target specific dashboards or even patterns of dashboards.