Bridging the Divide: Understanding Cross-System SoD Challenges Between Salesforce and S/4HANA

Executive Summary 

In our previous blog -“Unraveling Access Control: A Deep Dive into Salesforce and SAP S/4HANA Security Models” we laid the groundwork by exploring the distinct access control paradigms of Salesforce and SAP S/4HANA. Now, we shall have a detailed look  into the critical next step: understanding the inherent challenges of Segregation of Duties (SoD) that emerge, both within Salesforce’s complex layered structure and, most significantly, when business processes span across these fundamentally different systems. 

The Cross-System SoD Mapping Challenge 

While Salesforce offers granular controls, its layered nature already presents significant internal SoD challenges. These complexities are then exponentially magnified when considering cross-system interactions with SAP. 

The technical hurdle lies in mapping equivalent risk actions across SAP and Salesforce. What constitutes a risk in Salesforce (e.g., quote approval) must be mapped to a corresponding risk in SAP (e.g., issuing a credit memo). This is profoundly complex due to the fundamental differences in their authorization models. Salesforce’s layered permissions operate differently from SAP’s Authorization Objects, Fields, and Values. To perform a meaningful SoD assessment, these disparate structures must be translated into a common, unified framework—effectively, a ‘Rosetta Stone’ for access. 

This requires: 

• Entitlement Normalization: Structuring permissions from both systems into a unified schema (e.g., Permission, Action, Value). 

• Action Correlation: Identifying equivalent business functions that, when combined across systems, create a SoD conflict. 

• Rule Harmonization: Developing a consistent set of SoD rules that can be applied across the normalized data from both platforms. 

Consider these examples of how internal Salesforce permissions alone pose SoD challenges: 

• Object-Level SoD: A user with “Create” and “Delete” permissions on the “Invoice” object could create a fraudulent invoice and then delete the record to conceal their actions, bypassing critical audit trails. The powerful “View All” and “Modify All” permissions, often granted for convenience, can bypass standard sharing rules, enabling a single individual to unilaterally alter any record and complete a sensitive business process without oversight. 

• Organization-Wide Default (OWD) SoD Implication: If the OWD for “Customer Accounts” is set to “Public Read/Write,” and a user also holds a permission set allowing them to “Approve Credit Limit Increases,” this individual could unilaterally modify credit limits for any customer and then approve those changes, bypassing critical financial controls. 

• Record-Level SoD: A Sales Operations Specialist responsible for creating “Sales Quote” records, who also possesses permissions to “Approve Sales Quotes,” could create and unilaterally approve their own quotes, leading to unauthorized discounts. 

• Field-Level SoD: An HR Administrator with “Edit” access to the “Salary” field on “Employee” records (FLS) and the ability to “Approve Payroll Runs” could potentially inflate their own or others’ salaries and then authorize the corresponding fraudulent payment. 

• Folder-Level SoD: A user with “Manage” access to a “Sales Commission Reports” folder and “Edit” access to “Opportunity” records, combined with the ability to “Approve Commission Payouts,” could alter sales data, generate a manipulated report to justify inflated commissions, and then approve the fraudulent payout. 

These internal complexities are further amplified when cross-system interactions come into play. 

Cross-System SoD Conflict Example 

Building on the cross-system scenarios, let’s illustrate how AccessHub enables SAP GRC to detect violations: 

Scenario: Order-to-Cash Fraud 

Conflicting Access: A user with pricing override rights in Salesforce should not adjust orders in SAP simultaneously. 

Permission Required: Ability to create and convert opportunities/orders 

Business Process: Order to Cash 

Salesforce Activity: Create Opportunity and Convert to Order 

• Standard Object: Opportunity, Order 

• Required Permissions: Create, Read, Edit, Convert 

Salesforce Permissions: Create Opportunity and Convert to Order. A user has “Create” and “Edit” access on the “Opportunity” object in Salesforce, along with “Edit” access on the “Discount Percentage” field (FLS) for Opportunities. This allows them to create and modify sales opportunities, including applying discounts. 

SAP S4/HANA Activity: Sales Order Processing 

• Transaction Code (T-Code): VA01/VA02/VA31/VA32 

• Fiori App: Manage Sales Orders 

Fiori App ID: F1873 

SAP Authorizations: The same user possesses SAP authorization object V_VBAK_AAT (Sales Document Type), V_VBAK_VKO (Sales Organization), and V_VBAK_AKO (Order Reason) with change activity (VA02 – Change Sales Order). In addition, the user has authorization object F_BKPF (Accounting Documents) with activity 01 – Create and authorization object F_PAY_PROC (Payment Processing) with activity 03 – Process Payment. 

SoD Conflict: This combination allows the user to create or manipulate opportunities in Salesforce with unauthorized discounts, then adjust sales orders directly in SAP (VA02), and finally create accounting documents and process payments. This enables fraudulent transactions, bypassing the segregation of duties between sales opportunity initiation, sales order maintenance, and payment execution. 

Risk statement: A user who can create/convert Opportunities to Orders in Salesforce and create/change Sales Orders in SAP S/4HANA can originate an order in SFDC and then alter it in SAP (e.g., quantities, price, dates), bypassing approvals and price controls. If the SFDC user also has pricing override/discount powers, the risk severity is High. 

• SAP side (Function): SD05 – Sales Order Processing 

• Activities: Create/Change sales orders 

• Examples: T-codes VA01/VA31 (create), VA02/VA32 (change); Fiori app F1873 – Manage Sales Orders 

• Salesforce side (Function): F_SF15 – Create Opportunity & Convert to Order 

• Objects/Perms: Opportunity, Order with Create/Read/Edit/Convert (and, if present, Pricing/Discount override via CPQ or custom perms) 

Why it’s a problem (business impact) 

• Unauthorized discounts / margin erosion: Create/convert the deal in SFDC with a steep discount, then adjust order fields in SAP to slip past price approvals. 

• Order manipulation & revenue risk: Inflate/deflate quantities or ship/delivery dates in SAP after approval happened in SFDC. 

• Bypass of controls: Approval occurs in SFDC, but the same person changes the commercial terms in SAP where different controls apply. 

• Audit trail fragmentation: Activity is split across systems; without correlation it’s hard to detect. 

Example abuse path 

1. In Salesforce, user creates Opportunity, applies or overrides discount, converts to Order (or triggers order creation via integration). 
2. In SAP, the same user uses VA02/VA32 or F1873 to change price/quantity/terms before fulfilment/billing. 

The complexities of cross-system SoD are evident – identifying and mitigating these risks manually is virtually impossible. So, how can organizations effectively bridge this divide and gain comprehensive visibility into their hybrid access risks? In our final blog post of this series, ‘Beyond Detection: Streamlining Cross-System SoD with AccessHub for Salesforce and S/4HANA,’ we will unveil a powerful solution that simplifies this intricate challenge and enables robust, real-time SoD enforcement across your entire enterprise landscape. Don’t miss the conclusion to our deep dive!