Row-level security limits which records a person can see. Column masking hides or transforms selected values within accessible records. Attribute-based access control (ABAC) uses attributes of users, data or context to help determine access. These controls answer related but different questions.

A timely interview topic

Databricks announced ABAC support for views in Beta on 15 September 2026. Check the documented requirements before deployment. This guide uses a conceptual access matrix rather than executable policy syntax. Official release notes.

Start with known answers

Use three fictional orders: order 101 belongs to North and has $100 revenue; order 102 belongs to South and has $200; order 103 belongs to North and has $50. Each has a synthetic customer email. All monetary values are USD. The complete dataset totals $350; the North subset contains two orders and totals $150.

Write the intended policy first

A North analyst may read North orders but cannot see raw emails. A finance analyst may read every region’s revenue, also with emails masked. An approved support specialist may see raw emails for assigned cases only, which requires assignment data absent from this example. A user with no authorised role gets no access.

Masking emails in every row does not prevent the North analyst from seeing South revenue. Filtering to North does not hide North emails. Both controls are needed for the intended view.

Build a test matrix

• North analyst: orders 101 and 103, total $150, no raw emails.
• Finance analyst: three orders, total $350, no raw emails.
• Unauthorised user: access denied or an explicitly designed empty result, depending on the policy. Document the intended outcome.
• Revoked user: remove the entitlement, start a fresh session and verify access is gone. Investigate exported copies separately.
• Missing region attribute: confirm that a missing value cannot accidentally grant broad access.

Check every access route

Validate base tables, authorised views, dashboards and supported exports using realistic identities. A filtered dashboard does not prove that the user cannot query an unrestricted table. A downloaded spreadsheet may retain previously authorised data after live access is revoked; define export handling as part of the design.

Test combinations of roles too. A user in both finance and support may receive different effective access than expected. Policy-combination behaviour varies by engine; do not assume all systems resolve conflicts identically. Include a test where a user changes team or region.

Explain different totals correctly

If North sees $150 and finance sees $350, investigate access scope before treating the difference as a calculation bug. Reconcile under the same identity and filters. A label such as “revenue within your access scope” may prevent confusion.

Practice: Add a $75 South order. Finance should see $425; North should remain at $150. A changed North result needs investigation. Explain why a simple total check tests row scope but cannot prove that email masking works.

Next: BI engineering and reconciliation practice.

← All articles · Suggest a correction