SAP Build Process Automation

Work in SAP Build Process Automation is organized in projects:

1. A builder creates a business process project in the SAP Build lobby.
2. Inside the project, the builder models a process and adds artifacts: forms and approval forms for people, decision tables for rules, automations for repetitive desktop or system work, actions that call APIs, and subprocesses.
3. A trigger starts the process: a form, an API call, a business event, a schedule or a queue.
4. The builder releases the project, which creates a numbered version, and deploys that version to run it productively. Versions can be transported between tenants with SAP Cloud Transport Management.
5. At runtime, people receive their tasks in My Inbox in SAP Build Work Zone or in SAP Task Center, and automations run on a desktop agent in attended or unattended mode.
6. Monitoring tools and visibility scenarios show the state of process instances.

SAP Build Process Automation turns a process into a deployable, versioned artifact on SAP BTP.

SAP Build Process Automation consolidated two earlier SAP BTP services in 2022: SAP Workflow Management and SAP Intelligent Robotic Process Automation. SAP has since deprecated SAP Intelligent RPA, and both engines live on inside the new service with a reworked user experience. Workflows built with the earlier workflow capability can keep running and be reused as subprocesses, so existing customers can move at their own pace. Some SAP documents still use the earlier name SAP Process Automation. Since April 2025, SAP Build Process Automation is also offered as part of SAP Build under the build-default service plan. Older material describes the same concepts under SAP Workflow Management and its "workflow capability", a name that still appears in SAP Build Process Automation integration documentation.

• Several automation styles in one tool: human workflows, forms, decision tables, bots and process visibility share one project and one lifecycle.
• Low-code for mixed teams: business technologists start a process, and professional developers can add actions and advanced logic to the same project.
• Built for SAP integration: prebuilt content, actions based on SAP APIs, event triggers and native connectivity from SAP S/4HANA reduce integration effort.
• Clean core fit: processes run side by side on SAP BTP, so the ERP stays free of the extension's logic.
• Real lifecycle management: editable, released and deployed states, semantic versions and transports give citizen-built processes the same change control as other deployed software.

For processes that span systems or extend SAP standard on SAP BTP, SAP Build Process Automation is SAP's own low-code option.

• A separate runtime. Processes run on SAP BTP, not inside SAP S/4HANA. Every interaction with business documents goes through destinations, communication arrangements, APIs or events that someone must set up and maintain.
• Licensing shapes design. Participants and designers need different user entitlements, and API-heavy or high-volume scenarios can need additional API call or storage quota.
• Bots follow the screen. Desktop automations depend on the user interfaces they drive, so UI changes require bot maintenance.
• Visibility covers what is instrumented. Visibility scenarios show the events that participating systems send; steps that send nothing stay dark.
• Governance is the customer's job. Low-code lowers the entry barrier; ownership, naming, reuse and retirement of projects still need rules.
• Data center coverage. The service runs on the data centers SAP lists for it, and generative AI features on a smaller subset, so check the list before choosing a subaccount region.

These boundaries follow from the design: SAP Build Process Automation is a platform service that extends SAP systems from the outside.

SAP documents several integration paths:

• Start and control from the ABAP side: SAP S/4HANA, including Cloud Public Edition through a communication arrangement, can call an API to start and control process instances on SAP BTP.
• Embed in SAP Business Workflow: on the ABAP platform, a generic standard task hands a step to SAP Build Process Automation and waits for completion.
• Business events: the extensibility wizard in SAP S/4HANA Cloud links a business event of a standard app to a process, which then starts whenever the event occurs.
• Actions: action projects call SAP S/4HANA APIs, for example OData services, from process steps.

Choosing the SAP Build Process Automation integration path is a design decision of its own, because it determines where the process starts and which system holds the truth about its state.

Use a simple test: where does the process live?

A common mistake is rebuilding a delivered approval on SAP BTP: the document status, posting logic and audit trail then live in two places. The opposite mistake is forcing a cross-system process into one backend workflow. SAP Build Process Automation fits best where no single SAP system owns the whole process.