Omni Access Management: Row-Level, Column-Level, and Content Security Explained

"Who can see revenue data?" is the question that exposes whether your BI governance is real or theoretical. In Omni, the answer is layered: security lives at the connection, the model, and the content level, glued together by user attributes. Get the layers right and access control is auditable; mix them up and you're one shared workbook away from a compliance incident.

This guide follows the structure of the excellent access management cheatsheet maintained by Hawkfry Group in their community omni-resources hub — we partner with Hawkfry on Omni implementations and this is the mental model we use on real deployments.

---

The four layers

Think of Omni access control as four concentric rings, from hardest to softest:

1. Connection — what data can reach Omni at all
2. Model — what rows and columns a user's queries can touch
3. Model access — which developers can modify which models
4. Content — which dashboards and workbooks a user can open

The critical property: data restrictions win over content sharing. If a workbook is shared with someone whose data access is restricted, they see the workbook — without the data. That's the fail-safe that makes the rest of the system workable.

Layer 1: Connection-level restrictions

Administrator-controlled, applied globally to every query through the connection, and impossible for model developers to override. This is where strict organizational boundaries and compliance requirements belong — if a dataset must never be visible to a business unit, enforce it here, at the database level, not three layers up in a dashboard filter.

Layer 2: Row-level security in the model

Two mechanisms, for two scopes.

Topic-level RLS uses access_filters with user attributes — the clean, declarative option:

access_filters:
- field: products.brand
  user_attribute: customer
  values_for_unfiltered: [is_admin]

Every query through the topic gets filtered to the user's customer attribute value; users flagged is_admin see everything. If you're coming from Looker, this is the direct equivalent of access_filter on an explore — one of many concepts that map cleanly across.

View-level (field-level) RLS is done in SQL with user attributes, which gives you graded disclosure rather than all-or-nothing:

name:
  sql: ${users.full_name}

name_hidden:
  sql: |+
    CASE
      WHEN {{omni_attributes.see_names}} = 'true'
      THEN ${users.name}
      ELSE 'No Access'
    END

name_hashed:
  sql: |+
    CASE
      WHEN {{omni_attributes.see_names}} = 'true'
      THEN ${users.name}
      ELSE MD5(${users.name})
    END

The hashed variant is underrated: users without access can still count and group by the field (the hash is stable) without ever seeing a name. That keeps analysis possible while PII stays masked.

Layer 3: Column-level security

required_access_grants limits who can query a field, based on user attributes:

full_name:
  required_access_grants: region_access   # defined in the model file

It applies to individual fields, entire topics, or whole view files. Two things to internalize:

• The access_grant must be defined in the model file first — the field only references it.
• Grants gate direct access and queries, not internal references. A measure built on a restricted field still computes; the restriction controls who can select the field itself. Design your grants with that in mind.

Layer 3½: Model access for developers

Separate from data access: administrators control which developers can modify which models. Use it to carve out development sandboxes and to keep sensitive model components (the revenue logic, the PII views) editable by a small group even when many people can query them.

Layer 4: Content access via folders

Content sharing is deliberately simple: workbook owners share workbooks, folder owners can expose everything in a folder. Resist the urge to use content sharing as your security layer — it governs discovery, not data. The data layers underneath decide what renders.

Making it operational

The pattern that fails in practice isn't the YAML — it's user attributes drifting out of sync as people join, move teams, and leave. Assigning attributes by hand in the admin UI doesn't survive contact with a 200-person deployment.

Two tools fix that:

• omni-user-manager (Hawkfry Group) — pip install omni-user-manager, then sync users, groups, and user attributes from JSON/CSV sources, with full and partial sync modes. We walked through it in our Omni user management guide.
• The official Omni CLI — scriptable access to the users and admin APIs for everything else. See our CLI guide.

Wire attribute sync to your identity provider's group membership and the whole model becomes: IdP group → user attribute → access filter/grant. One source of truth, auditable end to end.

The checklist we run on audits

• Compliance-critical boundaries enforced at the connection, not in models
• Every topic with customer- or region-scoped data has an access_filter
• values_for_unfiltered limited to a named admin attribute, not scattered exceptions
• PII fields carry required_access_grants (and hashed variants where analysis must continue)
• Access grants defined centrally in the model file, referenced everywhere else
• User attributes synced from the IdP, never hand-maintained
• Folder sharing treated as discovery, with zero security assumptions attached

---

Labs4Change partners with Hawkfry Group on Omni implementations — they run platform administration and access management, we run migrations and the modeling layer. Book a free strategy call to talk through your Omni governance setup.