How Grafana organizations and folder permissions shape a shared instance
Access design in open-source Grafana means deciding who can see and change what inside one self-hosted server, and that decision starts with organizations. Every user belongs to at least one organization, and organization permissions govern dashboards and folders, alerts, playlists, users, data sources, teams, settings, plugins, annotations, library panels and service accounts. A single shared instance can hold several organizations, but each one is a separate permission space, so the first design question is whether two groups need their own space or only their own part of a shared one. Confirm the organization structure before you build dashboards, because moving content between organizations later is more work than creating the right layout at the start.
Within an organization, the working boundary is the folder. Teams are usually separated by giving each group its own folder and assigning Viewer, Editor or Admin rights on that folder, while the organization role sets the baseline for everyone else. Test the design with one real user per role before rollout: confirm that a Viewer cannot edit a shared panel, that an Editor in one team cannot change another team's folder, and that data sources you did not intend to expose stay hidden. Check the current behavior of each role against the Grafana roles and permissions documentation for your version, since the exact permission set changes between releases.
This design work is needed when several teams share one instance and their visibility requirements differ, when contractors or auditors need read-only access to a subset, or when a regulated group must be kept apart from general operations. Server administrators manage server-wide settings, users, organizations and licenses, and can view server statistics including total users and active sessions, so keep that role small and separate from day-to-day organization admins. Record who owns each folder and organization before go-live, because access reviews later depend on that ownership record.
Choosing between organizations, folders, teams and roles
The server administrator role sits above every organization on the instance. Grafana documents that a server administrator manages server-wide settings, users, organizations and licenses, and can view server statistics such as total users and active sessions. This is the only layer that can create or remove organizations and change instance-wide configuration, so it should be held by a small, named group rather than by every platform engineer.
- Server-wide settings: Changes to the configuration file, authentication options and the instance URL affect every organization at once.
- Users and organizations: Only server administrators can create organizations and assign users to them across the instance.
- Licenses: License handling is a server-level task, so it belongs with the people who own the Grafana contract.
- Statistics: Total users and active sessions are visible here, which is useful for capacity planning but also reveals who is signed in.
- Limits: Server administration does not replace folder or dashboard permissions inside an organization, so day-to-day access still needs the layers below.
Confirm with your team who holds this role today and whether it is also used for routine dashboard work, which is a common source of overbroad access.
An organization is the top-level container inside a Grafana instance. Every user belongs to at least one organization, and organization permissions govern dashboards and folders, alerts, playlists, users, data sources, teams, settings, plugins, annotations, library panels and service accounts. Because these objects are scoped to an organization, a user in one organization cannot see another organization's dashboards or data sources unless they are added to it.
- Strongest separation: Use separate organizations when two groups must not share data sources, dashboards or alert configuration at all.
- Per-organization settings: Data sources, plugins and alert rules are configured separately in each organization, so duplicated setup is the cost.
- Users in several organizations: One person can belong to more than one organization and switch between them, which affects who you audit.
- Not a substitute for folders: Splitting teams inside one organization is usually handled with folders and roles, not extra organizations.
- Operational cost: Each organization adds its own data source set, alert routing and ownership to maintain.
Ask whether any data source must be hidden from one group entirely, because that is the case that most often justifies a separate organization.
Inside an organization, folders are the main permission boundary for dashboards and their related objects. Permissions set on a folder apply to the dashboards inside it, and teams or users can be granted View, Edit or Admin access at that level. Folder design therefore determines who can see which operational data without creating a new organization.
- Ownership by folder: Arrange folders around the service, platform or business unit that owns the dashboards, so permissions follow ownership.
- Inherited access: Dashboards inside a folder take that folder's access, which keeps grants manageable as dashboards grow.
- Limits of folders: A folder controls dashboards, not the data behind them. A user who can open a dashboard may still reach a data source they should not query, so data source permissions need separate review.
- Shared content: Keep common panels and reusable dashboards in a folder that most users can view, and restrict editing to a smaller group.
- Nesting: Confirm in your Grafana version how nested folder permissions are inherited before relying on deep hierarchies.
Review which folders hold sensitive dashboards and whether the data sources those dashboards query are restricted to the same audience.
A team is a named group of users inside an organization. Teams do not carry capabilities on their own. Their value is that a folder or dashboard permission can be granted to a team once, and membership changes then flow through without editing each object. Teams are therefore a way to group people, not a way to grant new powers.
- Grant to groups: Assign folder access to a team so onboarding and offboarding change team membership rather than many individual permissions.
- Team sync limits: Automatic team synchronization from an identity provider is listed among features available only in Grafana Enterprise and Grafana Cloud, so open-source teams are maintained by hand or through provisioning.
- Not a role: Membership in a team does not make someone an Editor or Admin, so roles must still be set separately.
- Naming discipline: Team names should match the owning group in your directory so audit reviews are straightforward.
- Service accounts: Automated access uses service accounts rather than team members, and those need their own ownership and rotation.
Confirm how your identity provider group structure maps to Grafana teams and who maintains that mapping after go-live.
Roles set what a user can do inside an organization, while folders and teams set what they can reach. The three basic roles are Viewer, Editor and Admin. A Viewer can look at dashboards they have access to, an Editor can change them, and an Admin can manage the organization's settings and users. Choosing the lowest role that does the job limits the blast radius of a mistake or a compromised account.
- Viewer: Suitable for most consumers of operational dashboards, such as on-call staff and business readers.
- Editor: Needed for people who build or change dashboards and alerts, usually a smaller group than the viewing audience.
- Admin: Reserved for people who manage the organization itself, including its users, data sources and settings.
- Role is not object scope: An Editor can still be blocked from a folder they cannot access, so roles and folder grants must be read together.
- Enterprise options: Fine-grained role-based access control is part of Grafana Enterprise, so open-source roles are coarser and should be checked against your audit requirements.
Before finalizing, confirm the role list for your Grafana version in the roles and permissions documentation and test one user per role.
Which permission model fits which team structure
This table compares separate organizations, a shared organization with folders and teams, the Viewer, Editor and Admin roles, and service accounts. Read each row against your team boundaries, then confirm the data-source access route before you commit to a layout, because data-source permissions and team sync behave differently across editions.
| Model | When it fits | What it isolates | Operational cost to maintain | Data-source access to confirm |
|---|---|---|---|---|
| Separate organizations | Business units or customers that must not see each other's dashboards, users or data sources at all | Dashboards, folders, users, data sources, teams and alerts within each organization | Each organization needs its own admin, users, data source setup and alert routing, so duplicated setup grows with every new organization | Data sources are defined per organization, so confirm each one is configured and provisioned separately and that credentials are scoped to that unit |
| One organization with folders and teams | Several teams share one instance and need separate dashboards but a common set of data sources | Dashboard and folder visibility per team through folder permissions, not a hard tenant boundary | Low routine cost, but folder permissions must be reviewed as teams and dashboards change | Confirm whether team members can query shared data sources directly and whether data source permissions are needed to restrict them |
| Viewer role | Consumers who read dashboards and run existing queries but do not edit | Prevents dashboard and folder edits; does not limit which data a viewer can query through permitted panels | Low, since viewers rarely need individual configuration | Confirm which data sources the viewer's panels query, since viewing a dashboard can still reach any data source it uses |
| Editor role | Builders who create and change dashboards and panels inside folders they can access | Edit rights on permitted folders, with no server or organization administration | Moderate, since dashboard sprawl and ad hoc data source changes need periodic review | Confirm which data sources editors can add or change, because editing a panel can expose a data source they did not previously query |
| Admin role | A small number of people who manage users, teams, organization settings and data sources | Full control of the organization, including access that other roles cannot override | Ongoing, since admin rights should be few and reviewed regularly | Confirm admin ownership of data source credentials and who can rotate them when staff change |
| Service accounts | Automation such as provisioning scripts, backup jobs or CI pipelines that call the Grafana API | Non-human access scoped to a role, so scripts do not run under a person's login | Recurring, since tokens expire and need rotation and an owner for each account | Confirm the token scope and whether the account can read or change the data source configuration it touches |
What open source cannot do and where Enterprise RBAC or data source permissions apply
The open-source edition covers a lot of shared access, but several group-driven and fine-grained controls sit outside it. The cards below mark where those gaps appear, what they change in the design, and what to confirm before you commit to a model.
SAML sign-in is Enterprise or Cloud only
The authentication docs list SAML as available only in Grafana Enterprise and Grafana Cloud. If your identity provider is SAML-only, the open-source edition needs another path, such as OAuth or OIDC through a broker, before you can enforce single sign-on for Grafana. Confirm which protocols your identity provider supports and whether a broker adds an approved component to your architecture.
**Team sync is not in open source**
Team sync, which maps identity provider groups to Grafana teams, is documented as an Enterprise and Grafana Cloud feature. In the open-source edition, team membership and folder grants must be maintained by an administrator or by provisioning tooling you own. Plan who approves membership changes, how often they are reviewed, and how leavers lose access.
Active sync and SCIM are not available
Active sync and SCIM provisioning, which push user and group changes from the directory, are also limited to Enterprise and Grafana Cloud. Without them, deprovisioning depends on a documented offboarding step rather than an automatic one. Write that step into your joiner, mover and leaver process and test it against a real departure.
Finer roles need edition confirmation
The open-source edition ships with the built-in Viewer, Editor and Admin roles. Any permission finer than those, or any custom role, must be checked against the roles and permissions documentation for the exact edition and version you run. Do not assume an action is restricted to a role until you have verified it in a test instance.
Data source permissions need confirmation
Folder permissions control dashboards, but they do not by themselves restrict which users can query a given data source. Confirm whether data source permissions are available in your edition, and whether they cover query access or only visibility. Where a sensitive system must be isolated, a separate Grafana organization or a dedicated data source account may be the safer boundary.
How to set up organizations, folders, teams and service accounts
This sequence turns a shared open-source Grafana into a tested access model, where each folder, team and service account has a documented purpose and each role has been confirmed by signing in as a test user.
Define the organization model
Decide whether the instance needs one organization or several. Most teams keep a single organization and separate access with folders, and only create another organization when data, dashboards, data sources or users must be kept apart at the top level, because every user belongs to at least one organization and organization permissions cover dashboards, data sources, teams, alerts and service accounts. An administrator writes the decision down with the list of owners for each organization. Check: each planned user group maps to exactly one organization, and the server administrator can list those organizations in the server admin area.
Create folders as permission boundaries
Create one top-level folder per team or business area, then nest subfolders only where a different audience needs different access. Folders are the unit you grant permissions on, so keep dashboards that share an audience inside the same folder and avoid putting sensitive dashboards in the General area. An administrator creates the folder tree and records the owner of each folder. Check: a folder listing shows the planned tree, and each folder has a named owner before any user is added.
Assign teams and base roles
Create teams for each group of people who need the same folder access, then add members. Set the organization's default role for new users to the least privileged option, and give Editor or Admin only to people who build dashboards or manage the organization. Teams are not synced from your identity provider in the open-source edition, so the team membership must be maintained by an administrator or through your own automation. Check: each team lists its members, and the default role for new sign-ins is Viewer.
Grant folder permissions to teams
On each folder, grant View, Edit or Admin to the team that owns it, and remove broad grants that were inherited from the default. Use team grants rather than individual user grants wherever possible so membership changes do not require folder edits. Confirm the permission at the folder level, because dashboards inherit it. Check: the permission list for each folder shows only the intended teams, and no folder grants access to all Viewers by accident.
Set data source access
Review each data source and decide which organizations and roles can query it. In the open-source edition, folder permissions do not restrict which data source a dashboard panel can query, so a user with access to a dashboard can still reach any data source that the organization exposes to Viewers. Where that is not acceptable, separate the data into another organization or put the restriction in the data source itself, such as a database account with read access limited to the required schema, and confirm the exact data source permission options in your Grafana version. Check: a test Viewer in a team with no relation to a restricted data source cannot query it from an Explore view or a panel.
Create service accounts for automation
Create a service account for each script, pipeline or integration instead of reusing a person's login. Give it the lowest role that works, typically Viewer for read-only export or Editor for provisioning dashboards, and create a token with an expiry that the owner records. Store the token in your secrets manager, not in a repository. Check: the service account appears in the organization with its role, a call made with its token succeeds for the intended action, and the same call fails for an action outside its role.
Verify access with test users at each role
Create one test user for each role, Viewer, Editor and Admin, and one for each team that holds a restricted folder. Sign in as each test user and walk through the folders, dashboards, data sources and settings pages. A Viewer should see the folder without edit controls, and a user outside the owning team should not see the folder at all. Record the results and repeat this check after each upgrade or change to permissions. Check: every test user's observed access matches the documented matrix, and any mismatch is fixed before real users are onboarded.
Where shared Grafana access usually goes wrong
The most frequent failure in a shared open-source Grafana is editors saving dashboards into shared folders that other teams rely on. Organization permissions govern dashboards, folders, data sources, teams and service accounts, so an Editor with write access to a shared folder can change or replace panels that someone else depends on, and nothing in the folder itself records who approved the change. Data sources add a second exposure: in the open-source edition, a data source is an organization-level object, so any member of that organization who can query it can usually reach its full scope unless the data source is restricted by other means. Before go-live, list every data source and folder, confirm which role can write to each, and check which teams can see credentials-bearing connections. Confirm the exact behavior of your Grafana version in the Grafana roles and permissions documentation and in a test organization, since the permission model is where most surprises appear.
Service accounts are the second common problem. Teams create them for a dashboard export, a CI job or a reporting script, then grant the Admin or Editor role because the narrower role did not work on the first attempt. The result is a token that can change organization settings or users long after the original job has moved on. Assign each service account the lowest role its integration needs, give it a name that states its purpose and owner, and record an expiry or review date for every token. Access reviews also tend to stop once membership is managed by hand. Team membership changed in the Grafana interface with no ticket, so an access review means comparing two sources that no longer agree. If you use SAML, team sync or SCIM, check first whether those features are included in your edition, since the Grafana authentication documentation limits them to Enterprise and Grafana Cloud.
Provisioning files give you a reviewable record for the parts of the setup that should not drift. Data sources and dashboards can be defined in YAML or JSON files that Grafana loads at startup, so a change to a data source definition becomes a commit that someone reviews. The apiVersion and datasources keys in these files are the places where connection settings live, and a secret reference in them should point to a secret store rather than a plain value. Grafana also documents further as-code options, including Terraform and Git Sync, which can keep folder structure and permissions under version control. Provisioning does not replace periodic review of who holds which role, but it makes the folder and data source layout something you can diff, audit and restore. Decide which objects are owned by code and which are owned by dashboard editors before you build the first folder.
Security and operational controls for shared access
Shared Grafana access depends on a few controls working together: least-privilege roles, a clear split between server and organization administration, and authentication that stays with your identity provider. The cards below cover what the open-source edition supports and what to confirm before you rely on it for audit evidence.
Least privilege by role
Start every user at Viewer and grant Editor or Admin only on the folders or organizations where they change content. Most incidents in shared Grafana come from broad Editor rights granted for convenience, so review who holds Admin in each organization at a fixed interval. Check that new users land in the role you intend, because the default role assigned at sign-up or through the identity provider determines their starting access.
Server admin separated from org admin
A Grafana server administrator manages server-wide settings, users, organizations and licenses, which is a higher level than an organization Admin. Keep this role with a small platform team and give organization owners only the organization-level rights they need. Confirm who can create organizations and who can change server configuration, since both sit above any folder permission you set.
Reviewing service account tokens
Service accounts authenticate automation such as provisioning scripts and monitoring jobs. Each one should have a named owner, a single purpose and the lowest role that works. List tokens regularly, remove those tied to retired pipelines, and set expiry dates where your Grafana version supports them. Ask who can create tokens, because a token with Admin rights is effectively a standing administrator account.
Keeping authentication with the identity provider
Route sign-in through your corporate identity provider and disable local password logins for everyday users where your setup allows it. Under the open-source edition, LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab and Google OAuth are supported, but SAML, team sync and SCIM provisioning are Enterprise or Grafana Cloud features. Without team sync, team membership must be maintained in Grafana, so plan that manual process before you go live.
Recording folder permission changes
Permission changes on folders and dashboards alter who can see sensitive data, so they should be traceable to a person and a date. Decide where changes are recorded, whether in Grafana's own logs, a central log platform or a change ticket, and test that you can answer who granted a team Edit rights on a folder last quarter. Confirm the audit trail depth with Grafana for your edition and version before you describe it to an auditor.
Managing permissions as code
Where teams want repeatable access, define data sources, dashboards and their folder structure in provisioning files kept in version control, so changes go through review. Grafana's provisioning and as-code options, including Terraform and Git Sync, let you record intent in Git. Note that provisioned resources are often locked against UI edits, so agree on which team owns each folder before you adopt this pattern.
Questions teams ask before designing Grafana access
How much effort does designing Grafana access take, and what makes it grow?
Effort depends mainly on how many distinct groups of people need different views, how many data sources carry sensitive data, and how many folders must be separated. A small team with one set of dashboards can settle roles in a short working session. Effort rises when you must map Viewer, Editor and Admin roles to each team, decide which folders hold which data, and document who approves changes. Each data source and folder you add to the model adds review work. Cost comes from a written scope, so ask for the number of groups, folders and data sources included in the quote, and whether workshops, documentation and handover are part of it.
Is one Grafana organization enough for our teams?
For many teams, yes. Every user belongs to at least one organization, and organization permissions govern dashboards and folders, alerts, data sources, teams, plugins and service accounts. Separate organizations make sense when groups must have fully isolated dashboards, data sources and alert configuration, such as business units that cannot see each other's data. Within one organization, folders and team permissions often cover the same need with less overhead. Confirm with your data owners which data sources can be visible to which people before deciding, because a separate organization does not replace careful data source access planning.
What does our team need to provide before access design starts?
Prepare three inputs. First, a group structure: who works on which services, and who needs read-only access versus change rights. Second, a data source list with owners, including which systems hold sensitive or regulated data. Third, named owners for each folder or dashboard set who can approve access requests. Also list your identity provider and whether it can supply group membership. Open-source Grafana lets you manage teams manually, while team sync and SCIM provisioning are available only in Grafana Enterprise and Grafana Cloud, according to the Grafana authentication docs. Your identity provider choice therefore shapes how much work stays manual.
Can our own team configure Grafana permissions without a partner?
Yes, if you have an engineer comfortable with Grafana administration and a clear access model. Roles, folders and teams are set through the Grafana interface, and provisioning can define data sources and dashboards as files loaded at startup, which helps keep changes reviewable. The harder part is the design: deciding who sees what and why, and checking that nobody gains access through a path you did not intend. Many teams do the configuration in-house after a written design. A partner is useful when you want that design reviewed, when you lack time to document it, or when you need evidence for an audit.
When is Grafana Enterprise or a partner worth considering for access control?
Consider Grafana Enterprise when your identity provider integration must include SAML, team sync, active sync or SCIM provisioning, which the open-source edition does not offer according to the Grafana authentication docs. Also review the Enterprise role-based access control features if fine-grained permissions beyond the open-source roles are required. Check current licensing with Grafana Labs licensing, since editions and terms change. A partner is worth considering when the design must match audit expectations, when access must be enforced across many teams, or when you want an implementation done to a written scope.
Do folder permissions protect data inside dashboards from users who can query data sources?
Not always. Folder permissions control who can view or edit dashboards and folders, but they do not by themselves limit what a user can query. A person with access to a data source through another route may still reach the same metrics or logs. Plan data source permissions alongside folder design, and confirm with each data source owner which queries must be restricted. Document the boundary for each sensitive source, and test it with a user from each group before go-live.
How should service accounts fit into the access model?
Use service accounts for automation such as provisioning scripts, CI jobs or integrations, rather than sharing a person's login. Give each service account the narrowest organization role it needs, and record its owner and purpose. Rotate its tokens on a schedule you define, and review them when the owning team changes. Confirm how token lifetimes and rotation work in your Grafana version with the Grafana roles and permissions documentation before you write the policy.
How DeployOpen scopes Grafana access work
DeployOpen plans and implements self-hosted open-source platforms, including Grafana, inside the client's own infrastructure: their cloud accounts, data centers or air-gapped networks. For access design, that means the organization, team, folder and role model is built on your servers and tied to your identity provider, and the instance, its data and its administrators stay under your control. The access model described on this page is a design decision that DeployOpen works through with your team before any configuration is changed.
Most engagements are fixed-scope, so the access work is agreed in writing before it starts. A written scope for this topic should name the organizations to be created, the folder tree and the permission levels for each team, the number of Grafana server administrators, the service accounts that automation will use, and whether any part of the design depends on Grafana Enterprise features such as team sync or enterprise role-based access control. It should also state which deliverables you receive, such as the documented permission matrix, the provisioning files or Terraform code that recreate it, and the verification steps used to test it. Ask for these items explicitly when you compare quotes, because an access design that is not written down tends to drift after go-live.
Ongoing support is available as a retainer. Access models change as teams reorganize, new data sources are added and new people join, so many organizations use a retainer to review folder permissions, rotate service account tokens and handle role changes after the initial build. Confirm with DeployOpen during scoping which of these tasks sit inside the fixed-scope build and which would run under a retainer, and whether a retainer covers Grafana version upgrades that may change permission behavior.
