Name the role and action.
Replace a broad label such as “needs access” with a concrete task: view an assigned case, edit a draft or approve an export. Identify who can approve that permission.
Resources / Permission review
What should this person be allowed to do?
Use one real task to describe a permission decision. Keep private account details in your own controlled records.
Define the data boundary.
In a fictional service portal, an adviser may view assigned client cases but not another adviser's records. Describe both the allowed records and the records outside that boundary.
Follow connected actions.
Review downloads, search, background jobs and connected services as well as visible screens. Hiding a button is not evidence that the underlying action is unavailable.
Test allowed and denied paths.
Use authorized test accounts and suitable data. Record whether each role can complete its intended task and is denied the actions or records outside its scope.
Record exceptions and expiry.
Temporary access needs an owner and a review or removal point. A role change may require updates in more than one application.
Follow the account lifecycle or discuss a permission review.