Lesson 1 of 6
Where BPA fits next to S/4HANA workflows
12 min
Listen to this lesson
SAP Build Process Automation (BPA) is SAP's low-code service on SAP BTP for workflows, decisions, forms and robotic automations. Contoso Motor Co. already has approvals inside SAP S/4HANA: purchase requisitions over $10,000 go through a classic release strategy, flexible workflow routes purchase orders over $25,000 for approval, and approvers work in My Inbox. So the first question for Contoso's architects was not "how do we build in BPA" but "what belongs in BPA at all".
The short answer: approvals that live entirely on one S/4HANA business object stay in S/4HANA flexible workflow. Processes that span systems, people outside S/4HANA, documents, or decisions the business wants to own and change without a transport are candidates for BPA. Theo, the integration lead, and Kenji agreed a decision rule before anyone built a process.
| Aspect | S/4HANA flexible workflow | SAP Build Process Automation |
|---|---|---|
| Where it runs | Inside SAP S/4HANA, on a business object | On SAP BTP, side by side with S/4HANA |
| Typical scope | Approve one document: PR, PO, supplier invoice, journal entry | Cross-system processes, forms, documents, onboarding |
| Who configures | Key users in the Manage Workflows apps, within SAP-delivered scenarios | Citizen and professional developers in SAP Build |
| Business rules | Conditions and agent rules defined per scenario | Decisions (decision tables and text rules) owned by the business |
| Inbox | My Inbox in the SAP Fiori launchpad | BPA inbox apps (or SAP Build Work Zone) |
| Lifecycle | S/4HANA customizing and configuration | Project versions, environments, BTP transport |
Contoso's first BPA process
Contoso's fleet sales team onboards new fleet customers several times a month. Today it is e-mail and a spreadsheet: sales collects fleet size and expected volume, Maria (the order-to-cash key user) checks the master data, and Dan (finance process owner) approves the credit limit. The business partner already exists in S/4HANA when the work starts. That is a good BPA candidate: it starts from an S/4HANA event, needs a form, a decision and two approvals by different people, and writes a result back to S/4HANA through an API. Its working name is Fleet Customer Onboarding.
The building blocks
A project bundles these artifacts. You release a project to create an immutable version, then deploy the version to an environment. Environments, destinations and agents are administered in the SAP Build lobby's Control Tower. Running instances are watched in the Monitor area. Lesson 6 covers that lifecycle.
Who builds and who owns
SAP markets BPA to citizen developers as well as professional ones, and Contoso uses both, with clear lines. Key users in fleet sales may draft forms and propose decision rows in the DEV tenant. Kenji's team owns data types, actions, triggers and anything that writes to SAP S/4HANA, and reviews every project before release. Dan owns the credit decision, Maria owns the master data step, and Priya owns the test plan. The same project therefore has a business owner, a technical owner and a test owner, written into the placement record. That split is what lets a low-code process be changed quickly without becoming an untested back door into the ERP system.
| Role | At Contoso | Owns |
|---|---|---|
| Business owner | Dan (credit), Maria (master data step) | Rules, thresholds, approver groups, acceptance |
| Technical owner | Kenji's team, with Theo for events | Data types, actions, triggers, destinations, release |
| Test owner | Priya, with Wei for data and users | Test plan, evidence, sign-off summary |
Ownership of a BPA project at Contoso.
Where BPA does not fit
- High-volume system integration. Thousands of IDocs an hour belong in Cloud Integration, not in a workflow.
- Approvals SAP already delivers in S/4HANA. Rebuilding the PO approval in BPA would duplicate flexible workflow and lose its document context.
- Complex transactional logic. Deposit calculations and agreement rules belong in the RAP BO, not in process conditions.
- Ungoverned citizen projects. A process that writes to S/4HANA through an API is production software and needs the same testing and transport discipline.
What goes wrong in testing
- Duplicate approvals. A BPA process approves a PO that flexible workflow also routes. Testers see two approvals and nobody knows which one counts.
- Hidden S/4HANA dependency. The process calls an S/4HANA API that is not reachable from the test subaccount. Paths that write back fail only in QA.
- No owner for rules. A decision table nobody owns drifts from policy.
What would you do?
Grace's steering group asks whether Contoso should move the purchase order approval (over $25,000) from S/4HANA flexible workflow into BPA, "so all approvals are in one place". What should Theo recommend?
- Single-document approvals with an SAP-delivered scenario stay in S/4HANA flexible workflow.
- BPA fits cross-system, people-centric processes with forms and business-owned decisions.
- A BPA project bundles triggers, processes, forms, decisions, actions and automations.
- Processes that write to S/4HANA are production software: test and transport them like any other.
Check your understanding · not graded
Lesson check
1. Where should Contoso's approval of POs over $25,000 stay?
2. Why is fleet customer onboarding a good BPA candidate?
3. What does releasing a BPA project create?
4. Where are BPA environments and destinations administered?
5. Which flow belongs in Cloud Integration rather than BPA?