> For the complete documentation index, see [llms.txt](https://docs.harmony.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.harmony.io/dashboard-and-analytics/managing-dashboard-access-and-permissions.md).

# Managing Dashboard Access and Permissions

Harmony's role-based access control (RBAC) for dashboards lets you define precisely who can view and interact with your analytics content. Permissions are enforced at every level - from the dashboard itself down to individual widgets and the data source queries that power them. This means each user sees only the data they are entitled to view, without requiring separate dashboard builds for different audiences.

This article explains how dashboard permissions work, what each role can do, and how to configure sharing and access settings.

***

### How Dashboard Permissions Work

Access control is applied at three levels:

* **Dashboard level** - controls who can open and view a dashboard.
* **Widget level** - controls which widgets are visible to a given user within a dashboard they can access.
* **Data source level** - controls which underlying queries and data sources a user's role permits them to retrieve data from.

When a user opens a dashboard, Harmony evaluates their role at all three levels simultaneously. Widgets or data that fall outside their permitted scope are automatically hidden or restricted - no extra configuration is needed on a per-widget basis once roles are assigned correctly.

***

### Roles and What They Can Access

Harmony uses the following roles in the context of dashboard access:

#### Administrators

Administrators have full access to all dashboards, widgets, and data sources. They can create, edit, share, and delete dashboards, and they can manage permissions for other users and roles.

#### Analysts and Editors

Users with an analyst or editor role can view and, depending on their specific permissions, edit dashboards that have been shared with them. Their access to individual widgets and data sources is scoped to what their role permits.

#### Desk Operators

Desk operators have a focused access model. They can access dashboards that have been explicitly shared with them or with the desk operator role, allowing them to monitor relevant metrics without exposure to broader analytical content or sensitive data sources outside their scope.

#### Viewers

Viewers can open dashboards shared with them but cannot edit or reconfigure any content. Widget and data source restrictions still apply based on their assigned role.

***

### Sharing a Dashboard

You can share a dashboard with specific users or with an entire role group.

1. Open the dashboard you want to share.
2. Select **Share** from the dashboard actions menu (top-right corner).
3. In the sharing panel, choose one of the following:
   * **Share with a user** - search for the user by name or email address and select their access level.
   * **Share with a role** - select a role group (for example, Desk Operators or Analysts) to grant access to all users assigned that role.
4. Confirm the access level you are granting - typically **View** or **Edit**.
5. Select **Save** to apply the sharing settings.

Users who are added individually take on the access level you specify. Users who receive access through a role assignment inherit the permissions of that role.

> **Note:** Sharing a dashboard with a user or role does not override widget-level or data source-level restrictions. If a widget queries a data source the viewer's role cannot access, that widget remains hidden for them even after the dashboard is shared.

***

### Widget-Level Permissions

Individual widgets inherit the permission context of the viewer. When a user opens a shared dashboard:

* Widgets that query permitted data sources are displayed normally.
* Widgets that query data sources outside the user's permitted scope are not rendered for that user.

This behavior is automatic. You do not need to manually hide widgets per user - the system evaluates each widget's data source query against the viewer's role at render time.

If you notice a widget is unexpectedly hidden for a user, check that their role has the appropriate data source permissions configured.

***

### Data Source Permissions

Data sources can be restricted by role at the source level. This provides a foundational layer of control that cascades up through widgets and dashboards.

To review or update data source permissions:

1. Navigate to **Settings** > **Data Sources**.
2. Select the data source you want to configure.
3. Under the **Access** or **Permissions** tab, add or remove the roles that are permitted to query that source.
4. Save your changes.

Any widget that references a restricted data source will automatically be hidden from users whose roles are not listed in the data source's permitted roles.

***

### Best Practices

* **Use role-based sharing over individual sharing** where possible. Sharing with a role ensures that new team members automatically receive the correct access as soon as they are assigned the role, reducing manual upkeep.
* **Audit data source permissions before sharing dashboards broadly.** Because widget visibility is driven by data source access, reviewing data source restrictions first helps you predict exactly what each role will see.
* **Test access as a different role** by using the impersonation or preview feature (if available in your plan) before rolling out a shared dashboard to a large group.
* **Avoid granting edit access to desk operators** unless they need to customize their own views. Viewer or view-only access keeps dashboards consistent for operational use.

***

### Troubleshooting Access Issues

| Symptom                                                 | Likely Cause                                               | What to Check                                                         |
| ------------------------------------------------------- | ---------------------------------------------------------- | --------------------------------------------------------------------- |
| A user cannot see a dashboard                           | Dashboard has not been shared with them or their role      | Review the dashboard's sharing settings                               |
| A widget is missing for one user but visible to another | The user's role lacks access to the widget's data source   | Check data source permissions for that role                           |
| A desk operator cannot open any dashboards              | No dashboards have been shared with the desk operator role | Share at least one dashboard with the desk operator role              |
| A user with edit access cannot modify a widget          | Widget editing may require a higher role level             | Confirm the user's role includes edit permissions at the widget level |

If you continue to experience access issues after reviewing permissions, contact your Harmony administrator or reach out to Harmony Support.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.harmony.io/dashboard-and-analytics/managing-dashboard-access-and-permissions.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
