View All Permission

How View All Permission Works

View All permission is broader than ordinary row sharing, because it changes what the application considers visible at the object level. In practice, it lets a user read records they do not own and that would otherwise be hidden by sharing rules, so the permission model becomes the real boundary of visibility.

This matters because object-level scope is not the same as unrestricted access to the whole system. A user may still be constrained by object permissions, field-level controls, and other governance rules, but once View All is granted, record isolation within that object is intentionally weakened.

Why It Changes the Access Model

View All is a privilege decision, not a cosmetic reporting option. It can be used to support supervisors, auditors, support teams, or operational roles that need broad visibility without full edit rights, but it also bypasses the normal assumption that records stay segmented by ownership or sharing relationships.

That is why the permission has to be understood alongside the role, profile, or permission set that grants it. The security outcome depends less on the label itself than on which identities receive it, how widely it is distributed, and whether that distribution matches the job function that genuinely needs cross-record visibility.

For a broader control perspective, the difference between role-based, attribute-based, relationship-based and policy-based access models is easier to see in Authorisation Models Guide.

Common Security Consequences

Because View All overrides record-level sharing, the main consequence is overexposure. A user who only needs a subset of records can end up with visibility into sensitive customer, employee, case, or operational data across the entire object, which increases the blast radius of a mistaken grant.

The permission also complicates assurance. Teams can wrongly assume that object sharing protects the data, when in fact a single privilege can nullify that protection for one user or role. In environments with many custom permissions sets, that makes entitlement review and least-privilege design more important than the interface suggests.

Related privilege decisions often need to be treated as part of a wider access-control pattern, especially when broad visibility is paired with administrative or support duties. The same principle appears in Privileged Access Management Guide, which frames excessive privilege as a governance issue, not just a configuration detail.

How to Evaluate and Govern It

Organizations should treat View All as a deliberate exception that needs ownership, justification, and periodic review. The practical question is whether the role truly needs universal read access for that object, or whether a smaller support process, filtered view, or delegated workflow would achieve the same outcome with less exposure.

It is also worth checking whether the permission is being granted through multiple paths, such as profiles, permission sets, and custom roles, because duplicated grants are easy to miss. Where broad visibility is unavoidable, the surrounding controls should be stronger, with tighter assignment rules and clearer review of who can see what.

The control challenge is the same one that appears in cloud entitlement management: right-size the effective privilege, not just the nominal role. Cloud PAM and CIEM Guide shows why effective access often matters more than the role name on paper.

For a complementary view of just-in-time elevation and standing privilege reduction, see Just-in-Time Access and Zero Standing Privilege Guide.

Risk and Threat Considerations

View All becomes risky when it is used as a convenience grant rather than a tightly justified exception. The exposed records may include sensitive operational, personal, or financial data, and the broader the object scope, the more damaging a mistaken or unnecessary grant becomes.

Failure mechanism: An attacker, insider, or over-privileged user can abuse a broad read permission to enumerate data that should have remained segregated by ownership or sharing rules, then use that visibility to target sensitive records, business processes, or follow-on access.

Impact: The result can be data exposure, confidentiality loss, reconnaissance for later abuse, and a larger incident blast radius if the permission is combined with other excessive privileges or compromised credentials.

Practitioner Guidance

Governance implication: Treat View All as a high-trust access decision that belongs in entitlement review, because the security boundary shifts from row sharing to the permission grant itself. Make sure the approval owner can explain why broad object visibility is necessary and whether the role still needs it.

What to watch for: Look for permission-set sprawl, duplicated grants across roles, and users whose job function no longer matches the breadth of access they hold. If the permission is used to compensate for a weak process, the access model usually needs redesign rather than another exception.

Related resources from NHI Mgmt Group

• Consolidated Permission View
• When should organisations revoke an OAuth grant or third-party app permission?
• What is the difference between client identity and permission scope in MCP governance?
• Why do permission boundaries fail as a scale control for cloud access?