Concept and mechanism
An ACL associates a resource, an operation, and access conditions. Reading and writing are different operations, and table access does not imply passing every field evaluation. During diagnosis, first identify user, operation, table, and field. A rule can combine roles, data conditions, and a script; meeting only one dimension is insufficient when the others are also required. Current documentation distinguishes Allow-If and Deny-Unless. An applicable failing Deny-Unless rule can deny access before permission rules. Avoid summaries claiming that any favorable ACL authorizes everything. Test representative identities and review the elevation needed to administer rules without confusing it with end-user access.
Guided application
The CMDB maintains configuration and relationships relevant to understanding services. CSDM guides consistent use of tables and relationships; a large record count does not prove coverage, freshness, or ownership. During a reconciliation incident, stale relationships can lead APS to call the wrong team or underestimate impact. Confirm origin, owner, and last validation time. Security Center helps observe and improve posture, but a favorable score does not remove work on permissions, integrations, or data. Responsibility is shared with the provider: the organization still decides access and configuration for its environment. Preserve evidence and follow up exceptions. The aim is to explain observed results and reduce exposure without granting broad privileges merely to make a check pass.
Table read permission does not resolve a field read restriction.
Common pitfalls
Favorable ACL treated as universal access; populated CMDB treated as accurate inventory; score treated as guarantee.
Related topics: Instance, navigation, and context · Configuration, access, and interfaces · Records, collaboration, and analytics
Validate effective access and relationship quality with evidence.
Reference: ACL types · CSA blueprint January 2026