Suggested answer

I build a persona matrix first: a table of representative users, the records they should and should not see, and the expected access level for each. That artefact is the specification, and everything else verifies against it.

Then:

1. Automated tests using System.runAs to assert access for each persona against seeded records, so regressions get caught by the pipeline rather than by users.
2. UserRecordAccess queries to answer, for a specific user and record, whether they have read, edit, or delete access — the fastest way to settle a dispute.
3. The record's Sharing and Sharing Hierarchy views plus a query on the share table with its RowCause, to see not just whether access exists but which mechanism granted it.
4. A full-copy sandbox for volume-sensitive behaviour, because recalculation duration and skew problems do not appear in a developer org.
5. Business user validation against the matrix before cutover.

What I avoid is testing as an administrator, which proves nothing because administrators bypass sharing, and reviewing configuration in Setup, which confirms intent rather than behaviour.

Practice content for interview preparation; not an official vendor answer. Verify details against current product documentation.

Community comments (0)

No comments yet.

Sign in or create a free account to add a comment. Comments are moderated before they appear.

Plain text only, 3–2000 characters. A moderator reviews every comment before it is published.