SAP Business Partner Workflows

The following sections provide considerations when addressing common SAP workflows in STEP.

Workflow considerations

When considering workflow design, it is important to determine whether a Business Partner-centric or BP extension-centric workflow is most suitable for your organization’s governance practices.

In a Business Partner-centric workflow, the initiating user (requester) is provided with the ability to maintain general BP data and add or maintain multiple Business Partner extensions (sales area, company code, or purchasing organization) as part of a single task. This approach simplifies the experience for the requester, as their updates are bundled together and perceived as one change to the BP. It also reduces the number of workflows in the system and aligns naturally with initial onboarding scenarios where only one of each extension is typically introduced.

However, this consolidation introduces trade-offs. Different extensions are owned by different functional groups, meaning that one workflow must manage multiple approval paths. Governance clarity can be reduced since distinct data domains are bundled together.

In addition, concurrency is limited. Only one extension task can be in flight at a time for the same BP, which may delay processing when multiple teams want to extend the same BP simultaneously. Finally, the workflow design itself becomes more complex, as it must account for conditional logic across several extension types.

Alternatively, in a Business Partner extension-centric workflow, the requester must manage adding or maintaining BP extensions as separate and distinct tasks whose workflows are independent of the BP itself.

A potential drawback of this approach is that a single requester may need to create multiple tasks (e.g., BP general data, one or more sales area data, company code, or purchasing organization for suppliers) to make what they perceive as a single set of changes. This can feel cumbersome, especially in high-volume scenarios if the same user is handling a large number of BPs. The risk is that solution implementers will either over-consolidate (leading to overly broad responsibilities in one workflow) or over-fragment (leading to unnecessary task multiplication).

Clarifying this balance is important:

  • In creation of a new BP, consolidation usually makes sense because governance and sequencing are more straightforward.

  • For extensions (new sales areas, company codes, etc.) and changes to an existing BP, separation ensures that functional ownership, concurrency, and approval chains remain clear.

This distinction avoids cardinality pitfalls while focusing on the primary use cases companies encounter.

Ultimately, the choice between separate BP extension workflows and a single BP-anchored workflow depends on business priorities:

  • If minimizing requester effort and reducing workflow counts is the top concern, a BP-level model may fit best.

  • If governance clarity, functional accountability, and parallel processing are higher priorities, then separate workflows for each BP extension data type remain the stronger option.

The following workflow sections assume BP extensions are modeled as separate entity objects which require their own workflows to facilitate the onboarding and maintenance processes.

Onboarding new Business Partner (Customer / Supplier)

Onboarding SAP Business Partners can be a complex process and involves multiple stakeholders, each responsible for distinct aspects of the master data. The workflow configuration in STEP must accommodate the various objects that comprise a Business Partner and guide each functional team in their enrichment activities to the appropriate workflow states.

In onboarding flows where the BP serves as the anchor, related BP extension data objects are typically onboarded alongside the BP object in a single workflow.

This design decision is based on the practical reality that only one of each data entity is typically introduced as the BP itself is being onboarded, i.e., as a new BP is being onboarded it will only be associated with one sales area and company code initially. Hence, the respective sales area data and company code data objects are included in the single workflow.

This approach streamlines the initial onboarding process by reducing the number of hand-offs between multiple workflows, allowing more efficient orchestration of data. The same rationale applies to onboarding a new BP Supplier, where its associated purchasing organization data and company code data entities are included in the same workflow.

As previously mentioned, this consolidation of responsibilities to the sales manager / requester role is merely one practical variation of an onboarding flow. There may be other variations where the finance team is solely responsible for entering and reviewing company code data and the procurement team is solely responsible for entering and reviewing purchasing organization data. Regardless of the varied responsibilities, these are likely to have a minimal impact on overall workflow design.

While this consolidated approach works well for initial onboarding, a different model is needed when attempting to add additional sales areas or company codes to an existing BP Customer. In this scenario, new Sales Area Data and Company Code Data entity objects will be managed through dedicated workflows of each type. This will be addressed in the subsequent sections.

Workflow example - Customer onboarding

  1. BP creation (initiated by requester)

    • Minimal core attributes (legal name, address, account group) are entered

    • A duplicate check ensures no existing BP record should be reused instead

    • Sales manager provides sales area data (sales organization, distribution channel, division)

    • Sales manager provides company code data

    • Procurement manager provides purchasing organization data

  2. Finance review

    • Review company code data

    • Provide additional financial information

  3. Logistics review

    • Provide logistics information

  4. MDM compliance review

    • The MDM specialist (or for company code and purchasing organization, the finance and procurement users) performs a thorough review to ensure:

      • Data completeness and accuracy

      • Alignment with data governance rules

    • Once approved, the new sales area is activated in STEP and synchronized to surrounding applications and business processes for operational use.

Adding new BP extension to Business Partner

When extending a BP to cover a new sales area, company code, or purchasing organization, the process in STEP follows a structured, multi-role workflow. This ensures accurate data entry, compliance with governance standards, and proper routing through relevant departments.

Maintenance of core master data on the BP object (e.g., general attributes such as name, address, tax numbers) should be handled within a dedicated BP maintenance workflow. In contrast, the addition of new BP extensions, such as sales areas, company codes, or purchasing organizations, should be managed in separate workflows. Each BP extension requires its own dedicated task, ensuring that changes are routed through the appropriate governance processes.

The purpose of this separation is to avoid mixing different governance scopes; general BP data may change quite often, relatively, and require broader review across functional groups. Bundling general data maintenance tasks with BP extension data may complicate review and approval processes.

Furthermore, having dedicated workflows for BP extension data allows for multiple sales areas, company codes, or purchasing organizations to be concurrently onboarded for the same BP. This will be in the form of separate workflow tasks as the functional groups which review and approve this data are different, i.e., company code is owned by finance, sales area is owned by sales, and purchasing organization is owned by procurement. While it may be true in some cases that a requester may have all of the relevant information for each organizational group and even conduct the initial enrichment, the approvers of this data are still separate and distinct.

Below is an example of a workflow for adding new sales area to an existing BP. The same principle may also be applied to extending company code and purchasing organization.

  1. Initiation by requester

    • The requester (i.e., sales manager) searches for the existing Business Partner in STEP

    • From the Customer’s details screen, they navigate to the 'Sales Area Data' and click 'Add New Sales Area Data'

  2. MDM object creation

    • Business logic in the MDM system creates the new sales area data, references it from the Business Partner, and initiates them into their respective onboarding workflows

  3. Sales manager - sales area data

    • The sales manager modifies sales area–specific attributes (sales organization, distribution channel, division)

    • Sales-specific rules and validations are applied without involving other teams

  4. MDM specialist - compliance review and approval

    • The MDM specialist (or for Company Code and Purchasing Organization, the Finance and Procurement user) performs a thorough review to ensure:

      • Data completeness and accuracy

      • Alignment with data governance rules

    • Once approved, the new Sales Area and/or Company Code is activated in STEP and synchronized to SAP for operational use.

Maintaining existing BP extension for Business Partner

Maintenance of existing Sales Area for a Business Partner is also recommended to be carried out within the confines of dedicated workflows. This ensures all changes to existing data are tracked and historic data is captured within revisions, reducing risk.

In accordance with the previous section about adding new Sales Area to an existing BP, maintenance of existing Sales Areas, Company Codes, and Purchasing Organizations are also separate tasks apart from general data maintenance.

Though this description is focused on Sales Area, the same pattern is also applicable to maintenance of existing Company Codes and Purchasing Organizations.

  1. Initiation by requester

    • The requester searches for an existing Business Partner in STEP.

    • From the Customer’s detail screen, they may navigate to the 'Sales Area Data' tab and select one or more Sales Area Data entries from the table to modify. It is possible to select either a single Sales Area Data or multiple.

  2. MDM object creation

    • Business logic in the MDM system initiates the Sales Area Data object into a maintenance workflow.

    • If a single data entity was selected, then the user will be navigated to the details screen of the object in the maintenance workflow.

    • If multiple data entities were selected, then the user will be navigated to the task list of the maintenance workflow.

  3. Sales manager - sales area data

    • The sales manager modifies sales area–specific attributes.

    • It may often be the case that the sales manager is also the same user as the initiating requester.

  4. MDM specialist - compliance review and approval

    • The MDM specialist performs a thorough review to ensure:

      • Data completeness and accuracy.

      • Alignment with data governance rules.

    • Once approved, the new Sales Area and/or Company Code is activated in STEP and synchronized to SAP for operational use.