Conditional row-level access

Switch row-level filters based on the security context, and let an admin policy grant unrestricted row access on top of more restrictive policies.

Use case

You want different row-level filters to apply to the same group depending on who the user is. For example:

• Users in different regional groups should see only rows for their region.
• Admins should bypass row filters entirely, even when other policies restrict the same role.

You can express both patterns with access_policy by combining conditions, row_level.allow_all, and the OR semantics across policies that match the same group.

Data modeling

Region-based switching

Define one policy per region, and gate each policy with a conditions entry that checks the user’s security context. Only the policy whose condition evaluates to true contributes its row_level filter to the query — the others are skipped.

In the following example, users in the analyst group see rows for their region: members of the emea group are restricted to EMEA orders, and members of the amer group are restricted to AMER orders.

YAML

cubes:
  - name: orders
    # ...

    access_policy:
      - group: analyst
        conditions:
          - if: "{ security_context.groups and 'emea' in security_context.groups }"
        row_level:
          filters:
            - member: region
              operator: equals
              values: ["EMEA"]

      - group: analyst
        conditions:
          - if: "{ security_context.groups and 'amer' in security_context.groups }"
        row_level:
          filters:
            - member: region
              operator: equals
              values: ["AMER"]

In JavaScript, you can also express the same pattern by making row_level itself a function of securityContext and returning different filters depending on the caller:

YAML

cubes:
  - name: orders
    # ...

    access_policy:
      - group: analyst
        conditions:
          - if: "{ security_context.groups and ('emea' in security_context.groups or 'amer' in security_context.groups) }"
        row_level:
          filters:
            - member: region
              operator: equals
              values:
                - "{ 'EMEA' if 'emea' in security_context.groups else 'AMER' }"

Admin override with allow_all

To let admins bypass row-level filters that apply to a role, add a second policy for the same group that grants row_level.allow_all when securityContext.is_admin is true. Because policies that match the same group are combined with OR semantics, the admin policy unlocks every row regardless of the more restrictive analyst policy:

YAML

cubes:
  - name: orders
    # ...

    access_policy:
      # Region-restricted access for regular analysts
      - group: analyst
        row_level:
          filters:
            - member: region
              operator: equals
              values: ["{ security_context.region }"]

      # Admin override: full row access when the user is an admin
      - group: analyst
        conditions:
          - if: "{ security_context.is_admin }"
        row_level:
          allow_all: true

Composing boolean logic with conditions

conditions accept full boolean logic, so you can switch which row_level applies based on combined checks against the security context and user attributes. In YAML, use and, or, not, and parentheses inside { ... }. In JavaScript, use &&, ||, and !. Multiple conditions entries on a single policy are combined with AND semantics; multiple matching policies are combined with OR semantics.

In the following example, full-time analysts who are either admins or owners and are not contractors get unrestricted row access; everyone else in the analyst group falls back to the region-restricted policy above.

YAML

cubes:
  - name: orders
    # ...

    access_policy:
      - group: analyst
        conditions:
          - if: "{ user_attributes.is_full_time_employee and user_attributes.tenure_years >= 2 }"
          - if: "{ user_attributes.is_admin or user_attributes.is_owner }"
          - if: "{ not (security_context.groups and 'contractors' in security_context.groups) }"
        row_level:
          allow_all: true

Result

With these policies in place:

• Regional analysts see only rows for the region attached to their security context, because only the policy whose conditions match contributes its row_level filter.
• Admins see all rows, because the admin policy’s row_level.allow_all: true combines with the regional policy via OR semantics.
• Users without any matching policy are denied access by default.