View All permission is an application privilege that lets a user see records or objects across all users’ data, within the scope of that object. It overrides normal record-level sharing rules, so access control depends on the permission set, profile, or role model that grants it.
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.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | View All broadens read access beyond normal record sharing and needs least-privilege review. |
| AC-3 — Access Enforcement | View All is enforced through application access rules that override record-level sharing. | |
| IA-5 — Authenticator Management | Broader visibility becomes more dangerous when credentials or sessions are compromised. | |
| Recommendation — Minimize View All grants and review whether each role truly needs object-wide visibility. Ensure the application enforces record visibility consistently with the approved permission model. Rotate and protect credentials tied to any account granted broad object visibility. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | View All is an access-control decision that must be governed and reviewed. |
| A.5.18 — Access rights | View All should be assigned, reviewed, and revoked as an access right. | |
| Recommendation — Define and enforce who may receive broad object visibility under formal access-control policy. Review and remove View All as part of access-rights recertification. | ||
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.