> ## 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.

<AgentInstructions>

## Submitting Feedback

If you encounter incorrect, outdated, or confusing documentation on this page, submit feedback:

POST https://docs.omni.co/feedback

```json
{
  "path": "/administration/users/permissions",
  "feedback": "Description of the issue"
}
```

Only submit feedback when you have something specific and actionable to report.

</AgentInstructions>

# Managing data access with connection permissions

> Assign and test database connection, data model, and content-level permissions to control user access across your Omni instance.

User permissions are first set on the individual database connection then more fine-tuned permissions can be assigned to individual users or groups within the organization, streamlining the management process.

## Connection permission basics

<AccordionGroup>
  <Accordion title="Who can define connection permissions?">
    **Organization Admins** and users who have **Connection Admin** permissions for a connection can define connection permissions.
  </Accordion>

  <Accordion title="What are the connection roles?">
    Omni has six base connection roles, ordered from the **least** permissive to the **most** permissive:

    * No access
    * Viewer
    * Restricted Querier
    * Querier
    * Modeler
    * Connection Admin

    Organizations can also create [custom roles](/administration/users/custom-roles) that inherit a base role's core capabilities while restricting specific granular permissions, such as a **Querier** role without the **Upload data** permission.

    For the specifics of what each base role can and cannot do, refer to the [Permissions reference](/administration/users/permissions-reference).
  </Accordion>

  <Accordion title="Can default permissions be applied to a connection?">
    Yes. Using the **Base access** setting, you can assign the minimum role users will have for the models in the connection. More permissive roles can be set in the connection's **Model access** section. **Note**: The base role will override a less permissive role set in the **Model access** section.
  </Accordion>

  <Accordion title="Can permissions be set at the model level?">
    Yes! In the **Model access** section, you can assign granular permissions to users and user groups for specific models.

    <Tip>
      A connection's **base role** will override a less permissive role set in the **Model access** section.
    </Tip>
  </Accordion>

  <Accordion title="What permissions should I set to do [thing]?">
    It depends on what you want to achieve! Do you want to lock everything down, or only restrict access for some things? Or perhaps it varies by team or dataset?

    In the [**Common permissions scenarios guide**](/administration/users/permissions-scenarios), we've outlined some common scenarios and how to use permissions to achieve the desired result. For example, limiting access to folders based on the team a user belongs to.
  </Accordion>

  <Accordion title="Do connection permissions impact a user's license type?">
    Yes. Refer to the [User license types](#license-types) section for more information.
  </Accordion>
</AccordionGroup>

## Defining permissions for a connection

<Note>
  **Organization Admin** or **Connection Admin** permissions for the connection are required to define connection permissions.
</Note>

To access the connection's **Permissions** tab:

1. Click **Settings > Connections**.
2. Click the connection.
3. Click the connection's **Permissions** tab. On this page, you can define default access for the connection (**Base access role**) and assign permissions to users and user groups for specific models (**Model access**). If [custom roles](/administration/users/custom-roles) are defined, they will be included as options in these sections.

**Not sure what permissions to set?** Check out the [Common permissions scenarios guide](/administration/users/permissions-scenarios) to learn what permissions to set in specific scenarios, such as restricting access to datasets based on team.

## Testing data access

As you assign connection roles to users, you can [impersonate them](/administration/users/impersonate) to test what users can see. This can be helpful in preemptively surfacing access warnings, which will display when users attempt to access specific types of content.

See the [Access warnings](/share#access-warnings) guide to learn what an access warning is and how to resolve it.

## License types

Omni's licensing structure has three tiers: Viewer, Standard, and Administrator/Developer.

To calculate a user's license type, Omni looks at:

* The user's **highest Connection role** across all connections, **and**
* Whether the user is an **Organization Administrator**. These users will have an **Administrator** license by default.

The following table shows how license types match to connection roles. Refer to the [Permissions reference](/administration/users/permissions-reference) for more information about what individual connection roles can do in Omni.

| License type        | Connection role        | Permissions                                                                                                                                                                                              |
| ------------------- | ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **None**            | **No Access**          | ❌ Cannot view content built on the connection<br />❌ Cannot query (topics)<br />❌ Cannot use SQL queries<br />❌ Cannot modify shared model files<br />❌ Cannot modify connection settings                |
| **Viewer**          | **Viewer**             | ✅ Can view dashboards built on topics<br />❌ Cannot query topics<br />❌ Cannot use SQL queries<br />❌ Cannot modify shared model files<br />❌ Cannot modify connection settings                          |
| **Standard**        | **Restricted Querier** | ✅ Can create, edit, and view workbooks and dashboards<br />✅ Can query topics (UI and AI)<br />❌ Cannot use SQL queries<br />❌ Cannot modify shared model files<br />❌ Cannot modify connection settings |
| **Standard**        | **Querier**            | ✅ Can create, edit, and view workbooks and dashboard<br />✅ Can query topics (UI and AI)<br />✅ Can use SQL queries<br />❌ Cannot modify shared model files<br />❌ Cannot modify connection settings     |
| **Admin/Developer** | **Modeler**            | ✅ Can create, edit, and view workbooks and dashboards<br />✅ Can query topics (UI and AI)<br />✅ Can use SQL queries<br />✅ Can modify shared model files<br />❌ Cannot modify connection settings       |
| **Admin/Developer** | **Connection Admin**   | ✅ Can create, edit, and view workbooks and dashboards<br />✅ Can query topics (UI and AI)<br />✅ Can use SQL queries<br />✅ Can modify shared model files<br />✅ Can modify connection settings          |

## Custom roles

Custom roles allow organizations to create variations of base roles with specific permission restrictions — for example, a **Querier** role without the **Upload data** permission. Custom roles can be assigned to users, groups, and as the base access on a connection.

For details on creating and managing custom roles, see [Custom roles](/administration/users/custom-roles).