Who Can See the Salary Column
An HR application stores compensation data on an Employee record type. Access is currently controlled by a single group, HR Users, which grants view access to all employee records. Within HR there are three populations: generalists (should see name, department, title), compensation analysts (should additionally see salary and bonus), and HR leadership (should see everything plus audit notes). The team's plan is to create three record-level visibility rules keyed to group membership, and to hide the salary fields on the interface for generalists. A security review flags two concerns: a generalist who is also a compensation analyst by group membership, and the fact that the interface hiding is the only thing preventing generalists from seeing salary.
1. Evaluate the proposed design. Where does it fail?
Read the worked answer
The design fails on two independent axes, and the review is right to flag both.
1. Field-level security is being done in the UI only. Hiding a column on an interface is presentation, not access control. If a generalist can reach the record through any other surface - a report, an export, a related-record grid, an API, a process - the salary is exposed. Field-level access must be enforced at the data layer (field-level security / role-based field visibility on the record type), so that a user without the entitlement cannot retrieve the field regardless of interface. The UI hiding is a convenience, not a control.
2. Overlapping group membership. A user in both HR Generalists and Comp Analysts gets the union of visibility rules, which is the correct and expected behavior - but the team must decide deliberately whether that is intended. Usually it is: a compensation analyst is also an HR user. The real risk is the opposite - a generalist accidentally added to the comp group, or a broad group (e.g. All Employees) that quietly grants more than intended. Audit group membership, not just the rules.
The corrected design: record-level rules for row scope, field-level security for column scope, UI for usability. Three layers, each doing its own job.
2. How would you structure the groups and rules to be maintainable and auditable?
Read the worked answer
Groups (the source of truth for entitlement):
HR Generalists,Comp Analysts,HR Leadership- role-based, not person-based. Never grant access to an individual.- Nest groups where the hierarchy is real (Leadership ⊇ Comp Analysts ⊇ Generalists) if the business agrees that leadership sees everything analysts see. Explicit nesting beats duplicating memberships and makes the intent legible.
- Keep a separate, tightly controlled group for the sensitive field (salary/bonus) and for audit notes. Do not let "HR Leadership" be a catch-all that quietly includes contractors.
Rules:
- Row-level: one rule per population, expressed in terms of group membership, with the broadest rule last and most restrictive first. Test with a user who is in multiple groups.
- Field-level: salary/bonus visible only to Comp Analysts and Leadership; audit notes only to Leadership. Enforce at the record type, not the interface.
Auditability:
- Log access to compensation fields (who viewed, when) - this is the kind of data where "who looked" matters.
- Review group membership on a schedule; membership drift is the usual cause of leaks, not rule logic.
- Document the intended matrix (population × field) and test it, so a future change to a rule can be checked against the matrix rather than reasoned about from scratch.
The judgment: entitlement lives in groups, enforcement lives at the data layer, and the UI is the last and least important layer.