You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

Status

  Approved

Owner
Stakeholders

Issue

The purpose of this document is to describe the Delegation of Authority (DOA) feature as it exists across the following platforms: SAP SuccessFactors, SAP Ariba, Salesforce, and Icertis. It outlines how each system implements DOA, including its core functionality, configuration options, limitations, and use cases.


Recommendation

Recommended approach is option A, i.e., DOA matrix and Framework in S4 HANA.  

The key drivers to centralize the Delegation of Authority (DOA) in S4 HANA are:

  1. Reduced Post-Go-Live Maintenance: Maintaining the DOA matrix and framework directly in each system can lead to high ongoing maintenance efforts after deployment. Centralizing in S4 HANA minimizes this duplication and effort.

  2. Availability of Employee Data: Employee information will be maintained in S4 as Mini Master, facilitating a single source of truth. The organization hierarchy within S4 will be used to identify workflow approvers based on document amounts.

  3. Development Effort in Other Systems: Developing the DOA framework within iCertis and Salesforce involves significant development effort and complexity. Centralizing in S4 HANA reduces the need for extensive customizations across multiple platforms.

  4. Workflow Development in S4 HANA: The majority of workflows required for the project will be developed within S4 HANA, supporting a unified and efficient approval process.

Overall, centralizing DOA in S4 HANA offers benefits in maintenance efficiency, data consistency, and workflow simplicity. 
Copy
Good response
Bad response

Background & Context

Financial delegation of authority (DOA) is the process of assigning specific financial decision-making powers to individuals or groups within an organization. It defines who can approve transactions like expenditures, contracts, and budget allocations, along with their approval limits. DOA helps manage financial risks by controlling the size of commitments lower-level management can make on behalf of the organization.

The following transaction type will be subject to DOA approval.

Functional AreaSystemTransaction Type
SalesSalesforceSales Proposals 

Sales forceSales Quotations

iCertsisContracts < N years

iCertisContracts > N years

S4 HANASales Orders

S4 HANARebate Contracts
Credit ManagementS4 HANACustomer Credit Limits and Rebates

S4 HANASet-up Credit Limit

S4 HANAIncrease Credit Limit

S4 HANARelease Credit Limit Block

S4 HANABad Debt Write-off

S4 HANADispute Management / Write-off

S4 HANACredit Memo (Returns / Rebates / Contract Write-off)
Procurement & SupplyS4 HANASupply / Procurement Proposals and Contracts

S4 HANAPurchase Requisition

S4 HANAContracts < N years (Take-or-Pay / No Take-or-Pay)

S4 HANAContracts > N years (Take-or-Pay / No Take-or-Pay)

S4 HANAThird-Party (Supplier) Expenditure

S4 HANANon-Order Invoice (NOI)

S4 HANAOne-Time Vendor (OTV)

S4 HANAUrgent Payment Requests

S4 HANADown Payment Requests
Capital AssetsS4 HANACAPEX Projects and Assets

S4 HANADisposal and Write-off of Fixed Assets
InventoryS4 HANAProvision of Inventory

S4 HANAInventory Review Write-on / Write-off
Mergers & AcquisitionsNAAcquisitions & Divestments – Transactions

NALetter of Intent (LOI) – Non-Binding

NALetter of Intent (LOI) – Binding
TreasuryS4 HANABorrowing or Other Facilities

NAProvision of Corporate or Bank Guarantee



Assumptions

The DOA matrix will be governed by the executive leadership team and the approved group controller or designate.

Employee Organization data will be used to determine DOA Approval. 

Constraints

 N/A



Impacts

  1. As part of the Cutover activities, the Delegation of Authority (DOA) Matrix will need to be maintained and available for reference.
  2. We will need the DOA to be finalized for each process area during the Detailed Design phase. This will ensure alignment across stakeholders and readiness for testing.


Business Rules

Approval Process Principles

  1. Approval Basis

    • Approval decisions are determined by the Master data object, like cost centre, WBS, and Business Partner, in the document requiring approval.

  2. Final Approver

    • Each approval workflow task is routed directly to the Final approver identified in the Delegation of Authority (DOA) matrix.

    • The Final approver must be authorized to approve the entire transactional value within the relevant organizational boundary.

  3. Single-Step Approval

    • The process will follow a single-step approval approach.

    • No multi-step approvals will be implemented to minimize potential delays.

  4. Vacant Position Escalation

    • If the designated approver position is vacant, the system will automatically escalate the task to the next higher filled position in the organizational hierarchy.

  5. Eligible Approvers

    • The approver may be:

      • A permanent Syensqo employee, or

      • A contingent worker, provided they are officially appointed to the relevant position in SAP SuccessFactors.

  6. Task Centre
    • BTP Task Centre will be the central Inbox for all approvals from S4 Hana, Ariba, iCertis and Salesforce.


Options considered

Option A: DOA matrix and Framework in S4 HANA

As part of the overall solution, a custom table will be developed in S/4HANA to store the Delegation of Authority (DOA) Matrix.

Key components of the solution include:

  • A custom framework will be built to:

    • Read data from the DOA table and Employee mini master data.

    • Determine the final DOA approval based on above inputs.

    • Handle exceptions in a controlled and consistent manner to ensure the solution remains homogeneous across all process areas.

  • Base approval will be determined by individual workflow logic, leveraging master data objects such as:

    • Cost Center

    • WBS (Work Breakdown Structure)

    • Other relevant organisational data

    • Custom Table 
  • The final approval will be derived by applying the DOA framework on top of the base approval logic.

  • For external systems such as iCertis, Salesforce, and Ariba, the DOA approval data will be interfaced via API or file-based integration

Reference Technical Architecture would following. 

Maintenance of DOA will be centrally governed and access-controlled.

Option B: DOA matrix and Framework in BTP

As part of the this option a custom table will be developed in BTP to store the Delegation of Authority (DOA) Matrix. This will be using BTP BPA as business rule and CAP services to interface.

Key components of the solution include:

  • A custom framework will be built in BTP:

    • Read data from the DOA table

    • Employee and organization data need to read from Success factors. We have API to read data but may end up calling same static data for each workflow. 

    • Determine the final DOA approval based on above inputs.

    • Handle exceptions in a controlled and consistent manner to ensure the solution remains homogeneous across all process areas.

  • Base approval will be determined by individual workflow logic in S4 HANA, leveraging master data objects such as:

    • Cost Center

    • WBS (Work Breakdown Structure)

    • Other relevant organisational data

    • Custom Table 
  • The final approval will be derived by calling BPA on top of the base approval logic.

  • For external systems such as iCertis, Salesforce, and Ariba, the DOA approval data will be interfaced via API or file-based integration



Reference Technical Architecture would following. 

Maintenance of DOA will be centrally governed and access-controlled in BTP.

Option C: DOA matrix and Framework in respective cloud applications 

DOA Table and Framework to be created in each system. Employee and Organisation need to be interfaced to all the relevant cloud application. 

Key components of the solution include:

  • A custom framework will be built in respective System :

    • Read data from the DOA table. 

    • Employee and organization data need to read from Success factors. Currently as per solution approach we will not need API call from S4 as data will be available in mini master. We will need either Employee replication or API based integration from Success factor to iCertis/Ariba/Salesforce. 

    • Determine the final DOA approval based on above inputs.

    • Handle exceptions in a controlled and consistent manner to ensure the solution remains homogeneous across all process areas.

  • Base approval will be determined by individual workflow logic in S4 HANA,Certis, Salesforce, and Ariba leveraging master data objects such as:

    • Cost Center

    • WBS (Work Breakdown Structure)

    • Other relevant organisational data

    • Custom Table 
  • The final approval will be derived by on top of the base approval logic.


Maintenance of DOA will be governed and access-controlled in respective system.


Evaluation



Option A

Option B
Option C

DOA Maintainance

(plus)Centralize in S4 HANA


(plus)Centralize in BTP


(minus) Need to be maintained in relevant system


Integration 

(plus) API based Integration need to be developed for relevant system from 

S4 HANA


(plus) API based Integration need to be developed for relevant system from 

BTP

(plus)No Integration required 



Employe Replication

(plus) No Additional Development required as employe mini master will be

available in S4 HANA.

(minus) Additional integration will be required with BTP. if this is designed real 

time than cost of integration will be high. As this will required call to SF for

each workflow. 

(minus) Additional integration need to created for Ariba ,

ICertis & Salesforce for employee replication. 


See also


No files shared here yet.

Change log

Version Published Changed By Comment
CURRENT (v. 13) Dec 15, 2025 10:07 WENNINGER-ext, Sascha formatting change
v. 20 Dec 05, 2025 15:25 WENNINGER-ext, Sascha added stakeholders
v. 19 Dec 03, 2025 15:56 JAIN-ext, Dhiraj
v. 18 Dec 01, 2025 07:34 WENNINGER-ext, Sascha
v. 17 Dec 01, 2025 07:33 WENNINGER-ext, Sascha
v. 16 Nov 03, 2025 05:01 WENNINGER-ext, Sascha
v. 15 Oct 29, 2025 10:03 JAIN-ext, Dhiraj
v. 14 Oct 15, 2025 09:37 WEINERT-ext, Patrick
v. 13 Oct 07, 2025 14:45 JAIN-ext, Dhiraj
v. 12 Oct 07, 2025 14:42 JAIN-ext, Dhiraj

Go to Page History

  • No labels