CIOs should treat authority in SAP, Salesforce and ServiceNow as one governance problem with three different internal mechanisms. The mechanisms do not line up. SAP assembles access from business roles, catalogs and restriction values. Salesforce layers object and field permissions, permission sets, sharing settings and the role hierarchy. ServiceNow combines roles, groups and ACL rules. A policy that maps a job title to a fixed bundle of rights will therefore produce different effective access on each platform, and the gap usually appears only after several grants combine.
A redesign that holds up sets one shared intent across all three platforms: grant access from job responsibility, name an accountable owner for every access package, test what a user can actually do once grants combine, and keep evidence of privileged changes. Each platform then implements that intent in its own terms.
As an Amazon Associate I earn from qualifying purchases.
What “authority” means in this redesign
Here, authority means the effective ability to see data, change records, perform sensitive actions, administer the platform, or delegate access to someone else. Counting roles or profiles misses most of that. The useful question is what a named person can see and do after every grant, restriction, sharing rule and access control has been applied.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Why the same job produces different access
Authority accumulates on all three platforms, but through different constructs. A user rarely holds one clearly bounded grant. More often, several individually reasonable assignments overlap: a second business role, an extra permission set, a group membership, or an ACL that opens a resource the role review never examined. Reviewing any one of these in isolation is how excessive access survives a review cycle. The platforms also expose that accumulation in different places, which is why the governance rules can be shared while the testing has to be platform-specific.
#1 Best Overall
- Used Book in Good Condition
How each platform builds authority
SAP S/4HANA Cloud Public Edition
SAP’s model is built from IAM apps, business catalogs, restrictions, business roles and business users. Business roles gather catalogs and apps into access profiles for job functions. Restrictions narrow what a role can reach, typically to organizational units or data segments such as a company code or plant, depending on which apps are active in that role. The SAP authorization model describes this structure, and the SAP authorization concept covers how it is applied.
The detail that changes role reviews is overlap. SAP’s documentation describes an override/aggregation issue when a user holds multiple roles that carry the same restriction type with different restriction values. Each role can look correct on its own while the combined assignment reaches more company codes or plants than intended. Effective access therefore has to be checked across all assigned roles together.
This behavior is documented for S/4HANA Cloud Public Edition, with the authorization concept referencing version 2608. Do not assume the same mechanics apply to other SAP products or deployment models.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →In practice, tie each business role to a real job function, inspect which catalogs and apps it aggregates, and validate restriction values in combination rather than role by role. Record how business need and segregation-of-duties checks shaped each change, so the next reviewer can see why a restriction exists.
Salesforce
Salesforce separates data access from other authority. Object and field permissions define what a user can do with records and fields. Administrative, user and custom permissions add functional or system authority beyond the data layer. Record visibility then depends on the role hierarchy, organization-wide sharing defaults and other sharing settings. The Salesforce authorization guidance sets out these layers.
Salesforce recommends a Minimum Access profile as the baseline, with permission sets grouped around job functions so that permissions do not sprawl across users. User Access Policies can automate or manually manage permissions and licenses based on defined criteria, which reduces manual changes when those criteria are met. The Salesforce Admin Security Workshop on identity and access covers the same model in training form.
The main trap is treating permission sets as the whole picture. A user’s effective access also reflects profile capabilities, sharing and hierarchy, and the additional permission layers. Feature availability and configuration vary by edition and org, so confirm each setting in your own environment.
ServiceNow
ServiceNow’s user administration documentation states the core principle plainly: “Use roles to specify what different users and user groups can see and do.” Access control rules (ACLs) set the requirements for access to resources, so a role review alone misses the resource-level conditions that ACLs impose. See ServiceNow user administration.
The Security Center’s identity and access management pages include Access Analyzer, which inspects permissions for users, roles or groups. Identity and Access Audit tracks changes to users, groups, roles, memberships and ACLs. Its documentation describes a window covering changes from the last 30 days, with retention configurable up to 30 days. These are product settings, not a recommended retention period.
Vendor support access is a separate control. The SNC Access Control plugin can constrain which support employees have instance access and for what start and end period, as described in ServiceNow’s access control configuration guide. Infrastructure-level operational access remains necessary and tracked, and restricting support access may affect service levels. Treat instance access and infrastructure operations as two different questions.
Include roles, ACLs and group membership in every effective-access review. The pages cited here are from the Australia release, dated March 12, 2026, so confirm the behavior against your own instance’s release.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsComparing the three platforms
The table compares how each vendor’s documentation describes its control model. It does not rank the platforms on risk, cost or performance, because the cited documentation does not measure those.
| Axis | SAP S/4HANA Cloud Public Edition | Salesforce | ServiceNow |
|---|---|---|---|
| Primary constructs | IAM apps, business catalogs, restrictions, business roles, business users | Profiles, object and field permissions, permission sets and groups, role hierarchy, sharing settings, User Access Policies | Users, groups, roles, ACLs |
| Accumulation to check | Same restriction type carrying different values across assigned roles | Permission sets and profile capabilities, plus sharing and hierarchy | Roles and group membership evaluated alongside ACL requirements |
| Governance evidence in vendor documentation | Authorization concept and IAM Information System | Authorization guidance, user access summaries and reporting, least-privilege guidance | Access Analyzer and Identity and Access Audit |
| Audit evidence window | Not stated in the cited SAP pages | Not stated in the cited Salesforce pages | Changes from the last 30 days; retention configurable up to 30 days |
| Scope caveat | Documented for S/4HANA Cloud Public Edition; authorization concept references version 2608 | Feature availability and configuration vary by edition and org | Release-specific; Australia release pages dated March 12, 2026 |
A redesign framework that works across all three
Each step applies to all three platforms. The platform-specific work sits mainly in steps 1 and 3.
1. Inventory authority
Identify human, service, integration and administrator identities. For each, list the roles, permission sets and groups, catalogs, restrictions, ACLs and sharing rules that affect sensitive actions or information. An inventory limited to people leaves out service and integration identities, which the review still has to cover.
2. Define accountable access packages
Map each standard package to a job responsibility, a business owner, a technical owner, an approval route and a review cadence. Keep exceptional access out of standard packages. Every exception needs a recorded business reason and an expiry date.
Recommended Free Tools
3. Model effective access
Account for accumulation and inheritance, then test representative users and high-risk combinations in a non-production environment where possible. For each test, check two things: the access the user should have, and the actions that must be blocked. On SAP, the test covers all assigned business roles together. On Salesforce, it covers profile, permission sets, sharing and hierarchy together. On ServiceNow, it covers roles, group membership and ACLs together.
4. Prioritize sensitive authority
Start with administration, access delegation, security configuration, finance or customer data, bulk export, integrations and change capabilities. This is a suggested order of priority. The cited vendor documentation does not rank these categories, and your own risk appetite should set the final sequence.
5. Review and keep evidence
Trigger a review on joiner, mover and leaver events, organizational role changes, privileged grants and material changes to the permission model. Keep the decision record alongside the platform audit evidence, and export platform audit evidence before it leaves the platform’s own view, so that longer review cycles remain traceable.
6. Measure the program
Track stale or ownerless grants, time to revoke access after a role change, exceptional access that passes its expiry, review completion and remediation rates, and unresolved segregation-of-duties conflicts. The vendor documentation does not supply benchmark values for these measures, so set targets from your own baseline.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
When effective access does not match the design
Use these checks when a review finds access that the role design did not predict.
Quick Recap
- An SAP user sees data from a company code or plant outside their remit. Start with the combined restriction values across every business role assigned to that user.
- A Salesforce user sees records outside their business unit. Check organization-wide sharing, the role hierarchy and sharing rules before changing any permission set.
- A Salesforce user holds an administrative capability that the permission-set review did not show. Check the profile and the administrative, user and custom permission layers.
- A ServiceNow user can perform an action that the role review cleared. Check the ACL on the resource and the user’s group memberships, then run Access Analyzer for the user, role or group.
- A vendor support employee still has instance access. Review the support access settings in SNC Access Control, and weigh the potential service-level effect before shortening the period.
Where the vendor evidence stops
- The vendor documentation cited here includes no independent statistic on overprivileged users, breach rates, financial savings or review frequency. Treat any such figure as needing its own source before you rely on it.
- Identity governance and administration tools can support cross-application access reviews, provisioning and segregation-of-duties workflows. This article does not assess any specific product. Whether a tool supports your exact SAP, Salesforce and ServiceNow editions and configurations has to be confirmed with its vendor.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
