Skip to main content
If your organization manages data access through database-level role-based access control (RBAC), you can enforce that same security model in Omni. By mapping each database role to a separate Omni connection and using dynamic environments with user attributes, queries execute under the correct database role for each user — without requiring multiple models. This approach assumes the underlying data structure is the same across all roles. Individual roles may have access to a subset of the data, but none should reference objects outside the primary connection’s schema.

Benefits

  • Row-level security: Database policies applied to each role are enforced automatically, since Omni queries run as the connection’s database user.
  • Audit logging: Database logs reflect which role executed each query, providing a clear trail for compliance.
  • Resource management: Assign different compute warehouses or resource pools to specific roles to manage performance and cost.

Prerequisites

  • Administrative access to your database to create roles and service accounts
  • Organization Admin permissions in Omni

Steps

1

Create the primary connection

Create a connection using credentials for the most permissive role — the one that is a superset of all other roles you plan to use. This connection will serve as the base for your model.Refer to the Database setup guides for instructions specific to your data warehouse.
2

Create a connection for each additional role

For every additional database role you want to map, create a separate Omni connection using that role’s service account credentials.Each connection must be the same database type as the primary connection. The schemas should be structurally identical — if a model references an object that doesn’t exist in a role’s connection, queries for users on that connection will fail.
3

Add role connections as environments

  1. Navigate to the primary connection’s settings page.
  2. Click the Environments tab.
  3. Click New Environment and select one of the role connections you created in the previous step.
  4. Repeat for each additional role connection.
  5. Click Save.
For more details, see Dynamically switching database environments.
4

Create the user attribute

Create a user attribute that will map each Omni user to their database role:
  1. Navigate to Settings > Attributes.
  2. Click New Attribute.
  3. Choose a Reference name that describes the role mapping (for example, db_role). You’ll use this reference name when configuring the connection in the next step.
  4. Set a Default Value that corresponds to the primary connection’s role, so users without an explicit assignment fall back to the default.
  5. Click Save.
Be careful when setting the default value. The default role determines what data unassigned users can access.
Then assign the appropriate value to each user. This can be done:
  • Manually in Settings > Attributes > Users tab
  • Via the API using the User attributes API
  • Via SCIM through an identity provider like Okta, which can sync role assignments automatically
5

Enable dynamic environment assignment

  1. Navigate back to the primary connection’s Environments tab.
  2. Toggle Allow environments to be assigned dynamically to on.
  3. In the User attribute field, enter the reference name of the user attribute you created in the previous step.
  4. In the Values for the default connection field, enter the value that maps to the primary connection.
  5. For each environment connection, enter the user attribute value that should route users to that connection.
  6. Click Update.
6

Clean up extra models

When you created the additional connections in step 2, Omni may have auto-generated a model for each one. Since all roles share the primary connection’s model, delete any models that were created for the non-primary connections.
  1. Navigate to Settings > Connections.
  2. Click the connection for one of the non-primary roles.
  3. If a model was auto-generated, click Delete model on the connection’s settings page.
  4. Repeat for each non-primary connection.

Next steps

  • Verify the setup by impersonating a user with a non-default role and running a test query
  • Review your data models to confirm they don’t reference objects that are unavailable to restricted roles
  • If using an identity provider, configure SCIM to automatically sync role assignments as users are provisioned