The Interface That Leaked Salary Data
You built an Interfaces page for a 40-person department so managers can review their direct reports' performance notes. The page shows a grid of Employees filtered to the logged-in user's team using a filter on a 'Manager' field. Each record displays name, role, and a long-text 'Performance notes' field. A separate 'Compensation' table holds salary bands, linked to Employees. During a pilot, a manager reported seeing salary band values on the interface even though you never added that field to the grid. Separately, two managers say the grid shows zero records, and one says it shows everyone in the department. The interface is shared with 'Anyone with the link' because some managers lacked platform accounts at launch.
1. Why might salary data appear even though the compensation field was not placed on the grid, and how does the sharing setting compound this?
Read the worked answer
Two mechanisms are likely at play:
- Linked-record lookups/rollups: if any field on the grid pulls from the Compensation table (a lookup or rollup of salary band), that derived field renders the underlying values. Also, expanding a linked record from a grid can expose fields from the linked table if the interface permits record detail views. The salary data is reachable through the link, not just through a field you placed.
- Sharing model: 'Anyone with the link' means the interface is not gated by user identity. Any per-user filter that relies on the logged-in user cannot resolve, so the filter either fails open (shows everything) or fails closed (shows nothing) depending on configuration. That directly explains both the 'sees everyone' and 'sees zero' reports.
So the salary exposure is a field-permission/derived-field problem, and the inconsistent visibility is a sharing/identity problem. They are separate bugs.
2. Diagnose the 'sees zero' vs 'sees everyone' split and propose a fix that preserves the pilot.
Read the worked answer
The split is the signature of an identity-dependent filter running under an anonymous link:
- Managers with platform accounts and correct Manager assignments see their team.
- Managers whose Manager field value does not match their account (or who access anonymously) fall to zero or to the unfiltered set.
Fix sequence:
- Move off anonymous sharing for anything containing performance or comp data; require authenticated access so the per-user filter has an identity to bind to.
- Verify the Manager field values match account identities exactly (case, spacing, email vs name). Mismatches cause empty results.
- Test with a manager account in a private window to confirm the filter binds.
- Separate concerns: put performance notes on a restricted interface and compensation on its own interface with its own audience, so a single misconfiguration cannot expose both.
- Keep the pilot by inviting the pilot managers as named users rather than via link.
3. What interface-level controls would you add so that derived fields cannot leak the linked table's sensitive values?
Read the worked answer
- Audit every field on the grid, including lookups and rollups, not just base fields; a rollup of 'salary band' is a sensitive field even though it lives on Employees.
- Restrict record detail / linked-record expansion so users cannot drill into the Compensation table from the performance interface.
- Use field-level visibility so the linked field itself is hidden where not needed; if the grid does not need the link, remove it.
- Principle of least data: build a dedicated view or synced subset for the interface that excludes compensation columns entirely, rather than relying on the interface to hide them.
- Periodic access review: since interfaces can be shared broadly, re-check audience settings whenever fields are added, because adding a lookup re-exposes data without anyone touching the sharing config.