Team folders limitations
Team folders have the following limitations: you can select only one team owner per folder, and you cannot assign or change a team owner for repository-managed folders.
Grafana dashboards · all subjects
permissions
156 notes in this subject, read out of this brain and free to use. This is page 2 of 3.
Team Folders tab on team details page
Each team page includes a Folders tab that lists all folders owned by that team, showing Name and Full path columns.
Team folders feature toggle requirement
The `foldersAppPlatformAPI` feature toggle must be enabled to use team folders in Grafana OSS or Grafana Enterprise.
Permissions required for team folders
To use team folders, you need permission to create root-level folders or permission to create subfolders in the parent folder. To assign or change a folder owner in the UI, you need permission to manage folder permissions and read teams.
Create team folder when creating a team
When team folders are enabled, the New team page includes an option to auto-create a team folder. Select 'Auto-create a team folder' when creating a team, and Grafana creates a folder with the same name as the team and assigns that team as the folder owner. After creation, review and update folder permissions if needed.
Team folders overview and purpose
Team folders help associate folders with teams so admins and team members can find dashboards, library panels, and alert rules faster. They streamline setup by letting admins create and assign a dedicated folder when creating a team, establishing clear ownership from the start. A team folder is a regular folder with team association metadata and team-aware navigation, but it does not change or replace folder permissions.
Create new team folder from Dashboards
To create a new team folder from Dashboards: click Dashboards, click New and select New folder, enter a unique folder name, select 'Assign an owner to the folder', select the team in the Team dropdown, and click Create. Grafana creates a regular folder and stores the selected team as the folder owner.
Assign or change team folder owner
To assign or change the owner of an existing folder: click Dashboards, open the folder, click Folder actions and select Manage folder owner, select a team or clear the value to remove owner, and click Save owner. If a folder has a team owner, Grafana displays an 'Owned by' label in the folder header.
Team folder permissions model
Team folder ownership does not replace folder permissions. Team folders use the same permission model as any other folder. To grant team members access to a team folder, configure folder permissions for the team or for users, roles, or service accounts.
API key roles specify permissions
API keys specify a role—either Admin, Editor, or Viewer—that determine the permissions associated with interacting with Grafana.
Permissions required to migrate API keys
To migrate API keys, you need at least one of the following permissions: Administrator permissions, Editor permissions, or Service account writer.
Add user to organization as server administrator
A server administrator can add a user to an organization by signing in to Grafana, navigating to Administration > Users and access > Users, clicking a user, clicking 'Add user to organization' in the Organizations section, selecting an organization and a role, and then clicking 'Add to organization'. The first user added to an organization becomes the Admin by default. After the Admin role is assigned, other users can be added as Admins, Editors, or Viewers. The user must be created in Grafana first, and the server administrator must have Grafana server administrator privileges.
User must belong to at least one organization
A user must belong to at least one organization in Grafana. Users are added to organizations to gain access to organization resources such as dashboards, data sources, and playlists.
First user added to organization becomes Admin by default
When adding the first user to an organization, that user automatically receives the Admin role. After the Admin role is assigned to the first user, subsequent users can be added to the organization with Admin, Editor, or Viewer roles.
Organization administrator can invite or remove users without server admin privileges
An organization administrator who does not have server administrator privileges can still invite users to join their organization and remove users from their organization through the organization's Users section in organization configuration. This is an alternative to the server administrator workflow.
Remove user from organization as server administrator
A server administrator can remove a user from an organization by signing in to Grafana, navigating to Administration > Users and access > Users, clicking a user, clicking 'Remove from organization' next to the organization in the Organization section, and then clicking 'Confirm removal'. The server administrator must have Grafana server administrator privileges to perform this action.
Fixed roles for alerting granular access
Fixed roles provide granular access to alerting resources. Key fixed roles include: Silences Writer (fixed:alerting.instances:writer) for adding and updating silences, Instances and Silences Reader (fixed:alerting.instances:reader) for reading alert instances and silences, Notifications Writer (fixed:alerting.notifications:writer) for managing notification policies and contact points, Notifications Reader (fixed:alerting.notifications:reader) for reading notification policies and contact points, Rules Writer (fixed:alerting.rules:writer) for creating, updating, and deleting alert rules, and Rules Reader (fixed:alerting.rules:reader) for reading alert rules.
Basic alerting roles and their access levels
Grafana Enterprise and Grafana Cloud provide four basic roles for alerting: Admin, Editor, Viewer, and None. Admin and Editor both have write access to alert rules, notification resources (notification API, contact points, templates, time intervals, notification policies, and silences), alert enrichments, and provisioning. Viewer has read access to alert rules, notification resources, and alert enrichments. No basic role provides a blank canvas to assign fixed or custom roles for more precise permissions.
Full access fixed roles for alerting
Two fixed roles provide full alerting access: Full access (fixed:alerting:writer) grants all permissions from Rules Writer, Instances Writer, and Notifications Writer for adding, updating, and deleting alert rules, silences, contact points, and notification policies. Full read-only access (fixed:alerting:reader) grants all permissions from Rules Reader, Instances Reader, and Notifications Reader for reading alert rules, alert instances, silences, contact points, and notification policies.
Provisioning API and role-specific fixed roles
Three fixed roles control provisioning and related access: Read via Provisioning API + Export Secrets (fixed:alerting.provisioning.secrets:reader) provides alert.provisioning:read and alert.provisioning.secrets:read permissions. Access to alert rules provisioning API (fixed:alerting.provisioning:writer) provides alert.provisioning:read and alert.provisioning:write permissions. Set provisioning status (fixed:alerting.provisioning.provenance:writer) provides alert.provisioning.provenance:write permission and should be used with other regular roles like Notifications Writer and Rules Writer.
Contact point fixed roles
Three fixed roles control contact point access: Contact Point Reader (fixed:alerting.receivers:reader) grants alert.notifications.receivers:read for scope receivers:*. Contact Point Creator (fixed:alerting.receivers:creator) grants alert.notifications.receivers:create and alert.notifications.receivers.test:create for scope receivers:uid:-. Contact Point Writer (fixed:alerting.receivers:writer) includes all Contact Point Creator permissions plus alert.notifications.receivers:read, alert.notifications.receivers:write, alert.notifications.receivers:delete, and alert.notifications.receivers.test:create for scope receivers:*.
Templates and time intervals fixed roles
Fixed roles for templates: Templates Reader (fixed:alerting.templates:reader) grants alert.notifications.templates:read. Templates Writer (fixed:alerting.templates:writer) grants alert.notifications.templates:read, alert.notifications.templates:write, alert.notifications.templates:delete, and alert.notifications.templates.test:write. Fixed roles for time intervals: Time Intervals Reader (fixed:alerting.time-intervals:reader) grants alert.notifications.time-intervals:read. Time Intervals Writer (fixed:alerting.time-intervals:writer) grants alert.notifications.time-intervals:read, alert.notifications.time-intervals:write, and alert.notifications.time-intervals:delete.
Notification policies and inhibition rules fixed roles
Notification Policies Reader (fixed:alerting.routes:reader) grants notifications.alerting.grafana.app/routingtrees:get for scope notifications.alerting.grafana.app/routingtrees:*. Notification Policies Writer (fixed:alerting.routes:writer) includes all Reader permissions plus notifications.alerting.grafana.app/routingtrees:create, notifications.alerting.grafana.app/routingtrees:update, and notifications.alerting.grafana.app/routingtrees:delete for the same scope. Inhibition Rules Reader (fixed:alerting.inhibition-rules:reader) grants alert.notifications.inhibition-rules:read for scope inhibition-rules:*. Inhibition Rules Writer (fixed:alerting.inhibition-rules:writer) includes all Reader permissions plus alert.notifications.inhibition-rules:write and alert.notifications.inhibition-rules:delete for the same scope.
Admin and enrichments fixed roles
Full admin access (fixed:alerting:admin) grants all permissions from fixed:alerting:writer plus alert.notifications.receivers.permissions:read, alert.notifications.receivers.permissions:write, alert.notifications.receivers:readSecrets, and alert.notifications.receivers:updateProtected for scope receivers:*. Enrichments Reader (fixed:alerting.enrichments:reader) grants alert.enrichments:read. Enrichments Writer (fixed:alerting.enrichments:writer) grants alert.enrichments:read and alert.enrichments:write. External Notifications Reader (fixed:alerting.notifications.external:reader) grants alert.notifications.external:read for scope datasources:*. External Notifications Writer (fixed:alerting.notifications.external:writer) includes all Reader permissions plus alert.notifications.external:write for scope datasources:*.
Custom role UID scope stability warning
When creating custom roles with alerting.notifications.receiver actions, do not use a scope other than receivers:*. The UID used in the scope is not stable and changes whenever a contact point is renamed.
Example custom role for read access to alert rules in folder
A custom role for read access to alert rules in a specific folder uses the PUT access-control/roles endpoint with name custom:alert_rules_reader, and includes two permissions: alert.rules:read with scope folders:uid:UID_F, and folders:read with scope folders:uid:UID_F.
Example custom role for write access to alert rules
A custom role for write access to alert rules in a specific folder uses the PUT access-control/roles endpoint with name custom:alert_rules_updater, and includes five permissions: alert.rules:read (scope folders:uid:UID_F), alert.rules:write (scope folders:uid:UID_F), alert.rules:create (scope folders:uid:UID_F), alert.notifications.receivers:list (no scope), and alert.notifications.time-intervals:read (no scope). The last two permissions should be deleted if not using simplified notification routing.
How to assign alerting roles
To assign roles to a user, team, or service account: Navigate to Administration > Users and access > Users, Teams, or Service Accounts. Search for the user, team, or service account. Select the role you want to assign.
Service account token role for saved queries
A service account token with the Writer role is required to manage saved queries with the Grafana Terraform provider.
View dashboard source code via Grafana files endpoint permissions
Users can view dashboard source code through the files endpoint if they have Viewer permission or higher on the dashboard or its parent folder. This allows them to list files in provisioned folders and branches, read dashboard JSON content, and view folder structure and organization.
Edit dashboard source code via Grafana files endpoint permissions
Users can modify dashboard source code through the files endpoint if they have Editor or Admin permission on the dashboard or its parent folder. This allows them to create new dashboard files, update existing dashboard content, delete dashboards, and modify folder structure. When changes are saved through this endpoint, Git Sync commits those changes to the Git repository (or creates pull requests if branch protection is enabled), subject to Git repository permissions.
Graphite data source requires Organization administrator role
You must have the Organization administrator role to configure the Graphite data source. Organization administrators can also configure the data source via YAML with the Grafana provisioning system.
Permission to add Loki data source
Only users with the organization administrator role can add data sources to Grafana. Administrators can also configure the Loki data source via YAML with Grafana's provisioning system.
Configuration form requires Organization administrator or datasources:write role
The data source settings page shows only Delete and Back buttons with no configuration fields when the logged-in user has insufficient permissions. Only users with the Organization administrator role or a custom RBAC role with datasources:write permissions can access the data source configuration form.
Trace to logs permissions requirement
To configure trace to logs correlation in Grafana, you need Editor or Admin permissions.
PATCH /api/dashboards/uid/:uid/public-dashboards/:publicDashboardUid updates shared dashboard
Updates an existing shared dashboard. Endpoint: PATCH /api/dashboards/uid/:uid/public-dashboards/:publicDashboardUid. Required permission: dashboards.public:write with scope dashboards:uid:<dashboard UID>. Request body fields: timeSelectionEnabled (optional, boolean, default false), isEnabled (optional, boolean, default false), annotationsEnabled (optional, boolean, default false), share (optional, string, default 'public'). Response includes uid, dashboardUid, accessToken, createdBy, updatedBy, createdAt, updatedAt, timeSelectionEnabled, isEnabled, annotationsEnabled, share. Status codes: 200 Updated, 400 Errors (invalid json, missing fields), 401 Unauthorized, 403 Access denied, 404 Dashboard not found.
POST /api/dashboards/uid/:uid/public-dashboards/ creates shared dashboard
Creates a new shared dashboard. Endpoint: POST /api/dashboards/uid/:uid/public-dashboards/. Required permission: dashboards.public:write with scope dashboards:uid:<dashboard UID>. Request body fields: uid (optional, unique identifier, auto-generated if null), accessToken (optional, unique token, auto-generated if null), timeSelectionEnabled (optional, boolean, default false), isEnabled (optional, boolean, default false), annotationsEnabled (optional, boolean, default false), share (optional, string, default 'public'). Response includes uid, dashboardUid, accessToken, createdBy, updatedBy, createdAt, updatedAt, timeSelectionEnabled, isEnabled, annotationsEnabled, share. Status codes: 200 Created, 400 Errors (invalid json, missing fields, dashboard already shared), 401 Unauthorized, 403 Access denied, 404 Dashboard not found.
GET /api/dashboards/uid/:uid/public-dashboards/ retrieves shared dashboard
Retrieves a shared dashboard by dashboard UID. Endpoint: GET /api/dashboards/uid/:uid/public-dashboards/. Required permission: dashboards:read with scope dashboards:uid:<dashboard UID>. Returns object with fields: uid, dashboardUid, accessToken, createdBy, updatedBy, createdAt, updatedAt, timeSelectionEnabled, isEnabled, annotationsEnabled, share. Status codes: 200 Found, 401 Unauthorized, 403 Access denied, 404 Dashboard not found.
DELETE /api/dashboards/uid/:uid/public-dashboards/:publicDashboardUid deletes shared dashboard
Deletes a shared dashboard by dashboard UID and shared dashboard UID. Endpoint: DELETE /api/dashboards/uid/:uid/public-dashboards/:publicDashboardUid. Required permission: dashboards.public:write with scope dashboards:uid:<dashboard UID>. Status codes: 200 Deleted, 401 Unauthorized, 403 Access denied.
GET /api/dashboards/public-dashboards lists all shared dashboards with pagination
Lists all shared dashboards with pagination support. Endpoint: GET /api/dashboards/public-dashboards. Query parameters: perpage (items per page), page (page number). Required permission: dashboards:read with scope dashboards:uid:<dashboard UID>. Response includes publicDashboards array with objects containing uid, accessToken, title, dashboardUid, isEnabled, plus totalCount, page, and perPage fields. Status codes: 200 OK.
Create service account token endpoint
The endpoint POST /api/serviceaccounts/:id/tokens creates a new token for a service account. The request body requires name (string) and optionally secondsToLive (integer). The secondsToLive parameter defaults to 0, meaning the token never expires. The response returns id, name, and key (the actual token value) fields.
Create service account token permissions
Creating a service account token requires the serviceaccounts:write action with serviceaccounts:id:* scope.
Delete service account token endpoint
The endpoint DELETE /api/serviceaccounts/:id/tokens/:tokenId deletes a specific token from a service account. The response returns a message field confirming deletion.
Delete service account token permissions
Deleting a service account token requires the serviceaccounts:write action with serviceaccounts:id:* scope.
Service account response object structure
A service account object returned by the API contains: id (integer), name (string), login (string), orgId (integer), isDisabled (boolean), createdAt (ISO 8601 timestamp), updatedAt (ISO 8601 timestamp), avatarUrl (string), role (string), teams (array), and accessControl (object with permission booleans).
Service account API authentication
For On-Prem Grafana instances, the Service account API uses Basic authentication. For Grafana Cloud instances, a Bearer token must be used for authentication.
Delete service account endpoint
The endpoint DELETE /api/serviceaccounts/:id deletes a service account. The response returns a message field confirming deletion.
Delete service account permissions
Deleting a service account requires the serviceaccounts:delete action with serviceaccounts:id:* scope.
Search service accounts with paging endpoint
The endpoint GET /api/serviceaccounts/search?perpage=10&page=1&query=myserviceaccount searches service accounts with pagination. The perpage parameter defaults to 1000 and page defaults to 1. The query parameter is optional and searches within the name field; query values with spaces must be URL encoded. The response includes totalCount (used to calculate total pages), serviceAccounts array, page, and perPage fields.
Search service accounts permissions
Searching service accounts requires the serviceaccounts:read action with no specific scope.
Create service account endpoint
The endpoint POST /api/serviceaccounts creates a new service account. The request body requires name (string), role (string), and isDisabled (boolean) fields. The response returns id, name, login, orgId, isDisabled, createdAt, updatedAt, avatarUrl, role, and teams fields.
Create service account permissions
Creating a service account requires the serviceaccounts:create action with no specific scope.
Get service account by ID endpoint
The endpoint GET /api/serviceaccounts/:id retrieves a specific service account by its ID. The response returns id, name, login, orgId, isDisabled, createdAt, updatedAt, avatarUrl, role, and teams fields.
Get service account permissions
Reading a service account requires the serviceaccounts:read action with serviceaccounts:id:* scope.
Update service account endpoint
The endpoint PATCH /api/serviceaccounts/:id updates a service account. The request body can include name and role fields. The response returns the updated service account object with id, name, login, orgId, isDisabled, createdAt, updatedAt, avatarUrl, role, and teams fields.
Update service account permissions
Updating a service account requires the serviceaccounts:write action with serviceaccounts:id:* scope.
Get service account tokens endpoint
The endpoint GET /api/serviceaccounts/:id/tokens retrieves all tokens for a service account. The response returns an array of token objects, each containing id, name, role, created, expiration, secondsUntilExpiration, and hasExpired fields.
Organization synchronization from identity providers
Organization sync binds all users from an organization in Grafana and delegates user management to the identity provider. Users from identity provider groups can be assigned to corresponding Grafana organizations. Organization sync is currently only supported for SAML and LDAP, only basic roles can be mapped, and users do not need to be invited through Grafana. This feature is only available for self-hosted Grafana instances as Cloud Grafana instances have a single organization limit.
IAM integration benefits
Integrating with an IAM provider provides: centralized user management for roles and permissions, advanced security features such as multi-factor authentication and audit trails, SSO so users access Grafana with the same credentials as other applications, and immediate reflection of user additions and updates from the user database.
Internal vs external user management options
Grafana supports three approaches to user management: integration with an external identity provider through IdP integrations, Grafana's basic authentication if an external identity provider is not desired, or anonymous access if the Grafana instance should be accessible to everyone.