Executive Summary
Modern enterprises increasingly operate in hybrid environments where critical business functions span multiple platforms like Salesforce and SAP S/4HANA. Understanding their security models is the first step towards effective cross-system access governance. In this blog, co-authored by Yogesh Nikam- SAP IAG Consultant, we begin our journey by laying the groundwork: a look at the distinct security models of Salesforce and SAP S/4HANA, the foundational knowledge needed for effective cross-system SoD (Segregation of Duties).
The Technical Challenge: SoD Across Heterogeneous Permission Models
Salesforce and SAP S/4HANA implement fundamentally different models for access control. SAP uses a role-based structure with authorization objects and field-level values. Salesforce relies on a metadata-driven system with permissions set at the object, record, field, and folder levels. These fundamental differences are where the challenges begin, setting up the need for a deeper understanding of each system.
SAP Authorization Model
SAP’s authorization model is highly structured and granular, built upon the concept of Authorization Objects, which define permissions for specific actions or resources. These objects contain Authorization Fields that further restrict functions, which are then limited by specific Authorization Values. Users are assigned Roles, which are collections of these authorization objects.
The hierarchy can be visualized as:
Role → Profile → Transaction/ Fiori App (Action) → Authorization Object (Permission/Resource) → Authorization Field (Resource Extension) → Authorization Field Value (From Value, To Value)
(Note: Profiles are technically generated during role maintenance but are not part of the functional hierarchy relevant for access design.)
For example, an SAP authorization object like F_BKPF_BUK (for accounting documents by company code) includes fields such as:
- ACTVT (Activity)
- BUKRS (Company Code)
A user’s authorization for this object could be defined as ACTVT = ’01’ (Create) and BUKRS = ‘1000’, allowing them to create accounting documents only within Company Code 1000. This fine-grained control at the value level is a hallmark of SAP’s security model. For more details on SAP’s comprehensive Identity and Access Management solutions, refer to official SAP documentation.
Simplified SAP’s security model and Its GRC Access Control Mapping:
Salesforce Model
Salesforce employs a sophisticated, multi-layered security model designed to manage access, permissions, and data visibility with exceptional granularity. This framework, while powerful, is inherently complex.
- Organization-Wide Defaults (OWD): The foundational layer defining default baseline access for all users to records of a specific object. For instance, setting “Opportunity” OWD to “Private” means users can only see their own opportunities by default. Learn more about Org-Wide Defaults on Salesforce Help.
- Profiles: Define “what users can do” by setting baseline permissions for objects (e.g., Create, Read, Edit, Delete on “Account”), tabs, applications, and various system settings. Every user must have one profile. Explore Profiles in Salesforce.
- Roles and Role Hierarchy: Primarily govern data visibility, determining “what users can see” based on a hierarchical structure. A “Sales Manager” role, for example, would typically have access to view all opportunities owned by “Sales Representative” roles reporting to them. Understand Roles and Role Hierarchy.
- Permission Sets and Permission Set Groups: Additive collections of permissions that extend a user’s access beyond their profile. They offer highly granular control over specific features or objects, useful for temporary assignments (e.g., granting “Edit” access to a custom field without altering the main profile). Learn about Permission Sets.
- Sharing Rules: Create automatic exceptions to OWD and the role hierarchy, expanding record access. An example would be a sharing rule allowing a specific public group read-only access to all “Case” records in a particular region. Dive deeper into Sharing Rules.
- Field-Level Security (FLS): Provides the most granular layer, controlling the visibility and editability of individual fields within an object. A sales representative might see “Account Name” but be restricted from viewing “Credit Score” on the same Account record. Understand Field-Level Security.
- Folder-Level Security: Manages access to reports, dashboards, documents, and email templates housed in folders, controlling who can view, edit, or manage these aggregated business intelligence assets. Salesforce provides details on Report and Dashboard Folder Sharing.
The following table summarizes the key components of the Salesforce security model:
What’s Next?
Now that we’ve explored the intricate security models of Salesforce and SAP S/4HANA, the next logical question is: how do these distinct approaches complicate the critical task of Segregation of Duties, especially when business processes span both systems?
In our next blog post, “Bridging the Divide: Understanding Cross-System SoD Challenges Between Salesforce and S/4HANA,” we will delve into the complexities and common pitfalls of managing SoD in such hybrid environments.