Column and row masking — from FGAC policy authoring to rollout
When collection permissions aren't enough, hide specific columns and rows differently per user or group. The operational flow to author, test, and roll out a single fine-grained policy.
One-line summary — Collection permissions answer "can this user see this dataset?". Policies (FGAC) layer "which columns and rows can they see?" on top, per dataset. One policy is configured for one subject (a user or a group).
Prerequisites
- The delete permission on the dataset (typically Owner) where the policy will live. Without it, the Data access policies tab opens read-only.
- The users and groups that will receive the policy must already be registered in portal. (SSO and account provisioning are covered as a prerequisite in a separate tutorial.)
- An agreed one-line definition of how the masked result should look to the analyst. Policies change data semantics, so before rollout which columns turn into NULL and which rows pass through should be unambiguous.
1. One policy = one subject — a single-paragraph design note
When designing a policy, pick one subject (a user or a group) first and then define both axes — columns to hide and rows to allow — for that subject in one go. To apply the same logic to a different subject, add a separate policy. Multiple per-subject policies can coexist on a single dataset, and when a user queries the dataset, the policies of that user plus any group they belong to are all applied together.
| Decision | Recommended starting point |
|---|---|
| Whom to constrain | Group first. Per-user policies only as exceptions. |
| How many column masks | Within a single policy, one row per concern area (PII / financial / location). When areas mix, splitting into multiple policies lowers review cost. |
| Whether to apply a row filter | If analysts only need to see their own department's data, group + one row filter is the most natural pattern. |
2. Add a policy (3 min)
- From the dataset detail page, open the Data access policies tab. Without delete permission the tab opens, but the Add button is hidden.
- Click Add policy to open the policy form modal.
- In Select subject, type at least two characters to search for a user or group. Only users and groups inside your own permission scope appear in results.
- In the Column masking area, click Add column mask to add the masked columns one row at a time.
The most common starting points among the six mask types:
| Data area | Recommended mask type |
|---|---|
| Identifiers like names and emails | Show only the leading N characters (default N=4) for the readability/uniqueness trade-off |
| Amounts and transaction prices | Replace with NULL — to avoid confusion with 0 |
| Addresses and lat/long | Fixed text (**** by default) or remove |
| Comparing identifiers is needed but the body must stay hidden | Hash (SHA-256) — the same input maps to the same hash so matching still works |
3. Row filters (2 min)
In the same modal's Row filters area, define row constraints via Add condition. One condition has three slots: column · operator · value.
- Group combination: per group, toggle AND (all conditions match) or OR (any one matches). Groups can be nested for expressions like department is A or B and amount < 1,000,000 — up to three levels of nesting.
- Common operators:
IN(enter multiple values as tags),BETWEEN(start to end),IS NULL/IS NOT NULL(no value). - Without a row filter there is no row restriction — every row is visible, with the masked columns still applied.
Saving brings up a Policy created notice and refreshes the list immediately. If the subject is unset, save is blocked.
4. Test — query from the subject's seat (2 min)
After authoring a policy, query the dataset as a user who has the subject's role and confirm the result. If you aren't the subject yourself, one of two patterns usually applies:
- A pre-prepared test account placed into a temporary group, with the policy granted to that group → sign in as the test account.
- A colleague in another department asked to confirm whether the column is masked, with the result attached as a screenshot to your operational log.
When testing, check both:
- The masked columns still appear as columns in the result table — the schema stays the same, only values change.
- The row filter passes exactly the expected row count — compare total rows vs filtered rows in the dataset metadata.
5. Rollout — the last three things before going live (1 min)
- Notification — A one-line heads-up to the subjects: from when, which columns and rows will be hidden. This matters more when analysis result interpretation is affected.
- Agreed rollback procedure — Deleting the policy reverts that subject to role-based permissions only. The operations team should know the revert is immediate.
- Operational log — Policy add, edit, and delete events recorded in your operations tooling. Portal's own security audit log screen isn't separately specified yet, so this operational log is your primary audit trail.
Self-check
You can confirm this tutorial is complete via these five points.
- You added one policy with subject = a group on a single dataset.
- You applied at least two of the six column mask types together inside one policy.
- You applied one row filter group (AND or OR).
- You looked at the masked result once from the seat of a test account or a subject colleague.
- You recorded the policy addition and a one-line rollback procedure in your operational log.
Next steps
- The most common deployments are per-department sales reports and PII column masking. Solving department-level visibility with group + row filter in one shot lightens permission operations on the analyst-facing collection.
- For the full permission model in one pass, see Tutorial: Permission model at a glance.
- For how to register and sync the subjects (users and groups) into portal in the first place, see Tutorial: SSO and account provisioning in one page.
When the three Admin Tutorials together describe one consistent operational cycle, this bundle can graduate to a Platform Admin Path in a future round.