"This person cannot see that." Six checks, in order. Each rules out one layer, and doing them in this order means you never grant something to find out whether it helps.
One. Is the role actually assigned to that user? Not requested, not in a provisioning rule — assigned, visible on their record today.
Two. Has the role taken effect? Role assignment is not always instantaneous, and a user who has not signed out and back in may be carrying yesterday's session.
Three. Does the role carry the privilege the page needs? This is where a copied role that was forked before a quarterly update quietly falls behind.
Four. Does the page open at all? If yes, function security is satisfied and the rest is data. If no, stop here — the answer is in the first three.
Five. Does the user have business unit or organization access to the rows they expect?
Six. Is the data access set right for the ledger involved?
FOLLOW IT AND YOU WILL STOP GUESSING. The reason to work in this order rather than by instinct is that the layers produce almost identical symptoms — an empty page looks the same whether the cause is check three or check six — and every shortcut ends in the same place: an extra role granted, the symptom gone, and nobody able to say which change fixed it.
Write down which check failed before you change anything. That sentence is what turns an access fix into something you can hand to an auditor, and it is what the lab in Lesson 10 grades.