> ## Documentation Index > Fetch the complete documentation index at: https://docs.omni.co/llms.txt > Use this file to discover all available pages before exploring further. # Content sharing > Share Omni dashboards and workbooks with your team using links, folder permissions, and access controls for governed collaboration. export const XCircleIcon = ({label}) => { return {label && ` ${label}`} ; }; export const CheckIcon = ({label}) => { return {label && ` ${label}`} ; }; Sharing content with your team makes it easier to collaborate, improves decision-making across teams, and keeps everyone on the same page. It also saves time by ensuring stakeholders have access to key insights without constantly recreating or requesting the same reports. **Note**: Publishing a document using the draft/publish workflow doesn't inherently grant document access. The document's folder location and document-level permissions determine who can access it. Refer to the [Editing & publishing guide](/content/develop) for more information. ## Content access permissions Content access is determined by a user's assigned content access role. Roles can be assigned at the content level, but **Organization Admins** can also assign default content access roles for the entire [organization](#organization). ### Document permissions Users can be assigned the following roles on individual documents:

Ability	No Access	Viewer	Editor	Manager
View dashboards
View & explore workbooks
Update dashboards & workbooks
Delete folders they created
Manage permissions on content

### Folder permissions Content access roles on folders work differently than on individual documents. When you share a folder, permissions cascade to all documents and subfolders inside. Additionally, folder-level roles grant the ability to add and remove content from the folder, not just view or edit individual documents.

Ability	No Access	Viewer	Editor	Manager
Search for the folder & its contents
View folder contents
View dashboards & explore workbooks
Edit content in the folder
Add new content to the folder
Delete folder content
Manage folder and content permissions

Generally, it's considered best practice to assign the least permissive role that satisfies a user's needs. Refer to the [permissions scenarios](/administration/users/permissions-scenarios) for more information and examples of different permissioning implementations. ## Assigning access roles to content To grant content access, start by clicking the **Share** icon near the top right corner of any folder or document:

### Users and user groups To share content with individual users and [user groups](/administration/users/groups): 1. Click the **Share with users or groups** field. 2. Use the dropdown to select the users and groups you want to share the content with. 3. Use the access role dropdown (next to the **Share** button) to assign the user or group an access role. 4. Click **Share**.

#### Transferring ownership Content owners and managers can transfer ownership to other managers from the access role dropdown:

Organization

Use the access role dropdown in the **Organization** row to share the content with your entire organization. This role will be applied to users when they access the content unless they have explicitly been assigned a different role. Changes will be saved automatically. The access role you select applies to personal content you share from **My Documents** or content you move to your organization's **Shared** hub. When you grant an organization role to personal content, it is shared organization-wide while remaining in your **My Documents** folder. As the owner, you retain archive and restore rights on the content even after it has been shared with the organization.

A few settings can affect how you share content with your organization: * **Content organization** - When enabled, users can add content to the organization's **Shared** hub. Otherwise, users can only add content to folders that they have been granted access to. * **Default content access role** - Applies the selected role as the organization default when content is saved in the organization's **Shared** hub. For more information about these settings, refer to the [Organization settings reference](/administration/settings). ## Inheriting access roles When users create subfolders within existing parent folders, the creator of the original parent folder maintains ownership of the newly created subfolders. However, users who create the subfolders retain full ownership rights over any documents they place within the subfolders they created. The contents of a folder will inherit the [access role](#content-access-permissions) of the parent folder. Documents and subfolders may be assigned more permissive roles than the parent folder, but they can't have a less permissive role. For example, `Folder 1` requires an **Editor** access role or higher: Since **Editor** access has been applied to `Folder 1`, this means that any documents or subfolders it contains can only be assigned **Editor** or **Manager** access roles. Let's take a look at an example where `Folder 1` is assigned **No access**. With this implementation, the documents and subfolders it contains can be assigned any more permissive access role: This approach allows for more granular access control as permission levels can be **increased** for nested content, but they can't be decreased. In this last example, the content with the most permissions (**Manager**) is the most deeply nested: ### What can users see? When organizing content and assigning access, assume that folder names will always be visible. If a folder contains content that a user has access to, the user will be able to see the folder. The user will only be able to see the content they have access to within the folder, however. For example, `Folder 1` has a **No access** role, but it contains a document that the entire organization has access to. Users will be able to see the folder and the document. ## Requesting document access Users can request access to dashboards and the document owner will receive an email notification to approve or review the request.

The owner and any document managers can see and approve or deny outstanding requests from the document's **Share** dialog:

Keep the following in mind when using this feature: * AccessBoost cannot be requested, only standard Viewer/Editor/Manager content roles. Model level roles still dictate what level of content access a user can have. * Users must be Restricted Querier or higher to request Editor or Manager access to a document. * Not available in embed ## Controlling document interactivity A **Manager** or higher content role is required to access document settings. You can also choose what users who access your content can do by enabling or disabling different abilities, like scheduling and duplication. You can access these settings by: * Clicking **Settings** in the **Share** modal, or * Clicking **File > Document Settings** in a dashboard or workbook Admins can control the available abilities for all documents in the organization using the [**Document abilities setting**](/administration/content-permissions). If an ability isn't available in a document, it may be disabled at the organization level. ## Changing document URLs and identifiers Changing a document's identifier can make its URL more readable and easier to remember. This could also be used for updates to an embedded dashboard without requiring an engineer to point from one identifier to another by instead pointing to a fixed, immutable URL. You can access this setting by: * Clicking **Settings** in the **Share** modal, or * Clicking **File > Document Settings** in a dashboard or workbook The document's identifier must be unique. Additionally, note that changes will be reflected in real time. ## Boosting permissions with AccessBoost Admin permissions are required to enable AccessBoost unless the [**Non-administrators can enable AccessBoost on content** setting](/administration/content-permissions#accessboost) in **Admin > Content permissions** is enabled. AccessBoost allows content managers to enable permission boosting by ignoring an Omni user's [database connection role](/administration/users/permissions). When enabled, the user can run a dashboard or app and view all of the data that content shows even if they typically wouldn't be able to see content built using SQL. AccessBoost only alters the access to the data on dashboards and apps. AccessBoost still respects a user's connection role when the user runs a query at the workbook level. AccessBoost may be useful in scenarios where users with connection roles of **Querier**, **Modeler**, and **Admins** that want to share dashboard or app content with users that have lower level connection roles like **Restricted Querier** and **Viewer**. AccessBoost does not allow users with a connection role of **No Access** to access a document on that connection. **Note that AccessBoost does not**: * [**Allow users to bypass `access_filters`**](/modeling/develop/data-access-control) * [**Automatically bypass in-use `access_grants`**](/modeling/models/access-grants). If you want to bypass checks for content built on topics or views using the access grant, add an `access_boostable: true` property to the grant. * **Alter access to data when running queries in workbooks**. Only data access on dashboards and apps is affected. ### AccessBoost in embedded Omni Enabling AccessBoost for the **Organization** role also applies on content that is [embedded externally](/embed), which can pose security implications to consider. Typically, for embedded content Omni applies the **Viewer** connection role - which would **only** allow users to see content that is tied to [modeled topics](/modeling/topics); limiting data that is exposed to external customers. This means that embed users can view SQL content and content not built on topics. However, this also means that you could inadvertently expose data to embed users that you don't want them to see. ### Enabling AccessBoost AccessBoost is enabled using the [**AccessBoost setting**](/administration/content-permissions) in **Settings > Content Permissions > AccessBoost**. When enabled at the organization level, you can set AccessBoost: * For your organization's [**Default access role**](/administration/content-permissions) in **Settings > Content Permissions > Default Content Access** * At the content level, in the document or folder's **Share** modal ### Examples | Level | Description | Enabled | Disabled | | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Organization | An admin user can enable or disable AccessBoost at the organization level in the Admin settings under Administration > Content Permissions | Allows users who manage content to enable AccessBoost at the folder and document levels | Prevents any users who manage content from enabling AccessBoost on the folder or document levels | | Folder | Once an admin user has enabled AccessBoost in the Admin settings for Content Permissions the content manager users can choose to enable AccessBoost at the folder level. | Allows users with access to a folder to open any dashboards or apps in that folder, view the content of those dashboards or apps even if the user's connection role would prevent them from viewing that content. i.e. a dashboard or app built with SQL requires the user opening it to have a connection role of Querier or higher. | A user must have a viewer connection role or higher for content built off of modeled topics. Any content built with SQL requires users to have a connection role of Querier or higher. | | Document | A user managing their content can choose to enable AccessBoost at the document level | Allows users with access to the document to open and view the dashboard or app, but not workbook view, for a document even if the user's connection role would prevent them from viewing that content. i.e. a dashboard or app built with SQL requires the user opening it to have a connection role of Querier or higher. | Without AccessBoost, a user must have a viewer connection role or higher for content built off of modeled topics. Any content built with SQL requires users to have a connection role of Querier or higher. | ## Sharing content externally Omni has robust sharing functionality through [Delivery](/share) and [Embedding](/embed) which allows users and organizations to securely share the data in a variety of forms.

Customizing embedded content

The **Embed** tab in a document's **Share** dialog has several options to customize what content is embedded and how it displays to users:

* **Content** - Embed the document's **Dashboard** or the **Workbook** * **Appearance settings** - Define how the embedded content will display, including **Light/dark** mode and Omni **Theme** * **Include current filters in embed** - If enabled, currently-applied filters will be included in the embedded content * **Allow copy to clipboard for embedded content** - If enabled, users will be able to copy values to their clipboard from the embedded content. The generated iframe code will include a `allow="clipboard-write"`. ## Access warnings Access warnings will appear as a yellow asterisk (`*`) on dashboards and as an **Access Warnings** button in draft [apps](/visualize-present/apps) when a tile contains content that Viewers or Restricted Queriers won't be able to see. These warnings are visible only to document editors — users with a Viewer or Restricted Querier connection role will simply see a blank tile.

Viewers and Restricted Queriers can only run topic-based queries. Any tile that uses raw SQL, references fields outside a topic, or is in a workbook that modifies security-relevant model properties will produce a warning. If a tile depends on another restricted tile, it is also flagged. ### Warning reasons #### Query-structural issues These warnings mean the tile itself is built in a way that Viewers and Restricted Queriers cannot run. | Reason | What it means | Fix | | ------------------------ | ---------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | | Raw SQL | The tile uses a hand-written SQL query instead of a modeled topic query. | Rebuild the tile using a topic, or save the SQL as a [query view](/analyze-explore/saved-views) and include it in a topic. | | No topic selected | The query has no topic associated with it. | Assign a topic to the query. | | Fields outside the topic | The query includes fields from views that aren't part of the selected topic. | Remove those fields or switch to a topic that includes them. | | Topic not found | The topic this tile was built on no longer exists — it may have been renamed or deleted. | Reassign the tile to a valid topic. | | Invalid model | The model or branch referenced by the query can't be resolved. | This usually indicates a stale query; re-open the tile and re-save. | #### Access grant issues These warnings mean the topic or field requires an [access grant](/modeling/models/access-grants) and either the grant itself or the user's attributes are the problem. The three reasons have different fixes: | Reason | What it means | Fix | | ------------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | | Grant not defined | A topic or field references an access grant name that doesn't exist in the model's `access_grants:` block. | Define the missing grant in the model, or remove the `required_access_grants` reference. | | User lacks the grant | The user's [attributes](/administration/users/attributes) don't satisfy the grant's `allowed_values` condition. | Update the user's attributes, or adjust the grant's `allowed_values`. | | Grant definitions changed | The workbook modifies which access grants are required on a view or topic. | Move the grant change to the shared model, or restructure the workbook to avoid modifying grant definitions. | #### Workbook model changes These warnings mean the workbook itself contains model-layer modifications that Viewers and Restricted Queriers aren't permitted to be exposed to. The fix is to move the relevant model change to the shared model, or restructure the workbook to remove it. | Reason | What the workbook changed | | ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------- | | Custom topic definitions | Defines topics beyond what's permitted (only AI-generated or simple upload topics are allowed in shared workbooks for restricted users). | | Relationship changes | Adds join relationships that aren't rooted in the shared model. | | Default access filters | Sets `default_topic_access_filters` at the model level. | | Default required access grants | Sets `default_topic_required_access_grants` at the model level. | | Model extends | Uses `extends:` to pull in another shared model. | | Dynamic shared extensions | Defines `dynamicSharedExtensions` (user-attribute-driven model layers). | | Field sets | Defines or removes field sets. | | SQL preamble | Adds a `sql_preamble` that runs before every query. | | Removed security properties | Deletes inherited security properties (access filters, extends, SQL preamble) from the parent model. | ### Resolving access warnings 1. **Fix the query or workbook** — see the fix column in the tables above for the specific action per reason. 2. **Enable [AccessBoost](/share#boosting-permissions-with-accessboost)** — bypasses connection role restrictions for dashboard and app viewers. Use with caution; AccessBoost does not bypass `access_filters` or access grants unless `access_boostable: true` is set on the grant. If your query is built from **raw SQL** and you save it as a query view, make sure you either include it in a topic or make a new topic for that query view, or you will continue to see access warnings on your dashboard.