Workflow + RPA
GA

SAP Build Process Automation

End-to-end process automation on SAP BTP — combining BPMN workflow automation, business rules, approval forms, process visibility, and robotic process automation (RPA) in a single low-code service. Integrates natively with SAP S/4HANA, SAP CAP, and SAP Build Work Zone Task Center.

What is SAP Build Process Automation?

SAP Build Process Automation is a managed service on SAP BTP that enables organisations to automate end-to-end business processes without writing code. It combines workflow automation (multi-step approval flows, conditional routing, parallel processing) with robotic process automation (RPA) (attended and unattended desktop bots) and business rules (decision tables) in a single platform.

Human tasks are routed to the SAP Build Work Zone Task Center — a unified inbox that aggregates approval items from SAP Build Process Automation, SAP S/4HANA Flexible Workflow, SAP SuccessFactors, SAP Ariba, and SAP Concur.

Formerly SAP Process Automation
SAP Build Process Automation was previously named "SAP Process Automation" and is the evolution of SAP Workflow Management combined with SAP Intelligent RPA. The product is available in the SAP Build suite and also accessible as a standalone BTP service subscription.

Quick Facts

Product
SAP Build Process Automation
Abbreviation
Build PA
Runtime
BTP Managed Service
Process Notation
BPMN 2.0-based visual editor
Human Tasks
Work Zone Task Center (unified inbox)
Business Rules
Decision tables, rule sets, rule services
RPA
Attended + unattended bots (Desktop Agent)
Triggers
REST, Event Mesh, S/4HANA events, schedule
Included In
GROW with SAP, Build Suite
Availability
Generally Available

Video Tutorials

Official SAP channel walkthroughs — click any card to play

SAP Build Process Automation — Build Your First Workflow20:15

SAP Build Process Automation — Build Your First Workflow

SAP Developers
Beginner
SAP Build Process Automation — Release, Deploy & Test Workflow18:40

SAP Build Process Automation — Release, Deploy & Test Workflow

SAP Developers
Intermediate
Start Automating Your Work with SAP Build Process Automation55:00

Start Automating Your Work with SAP Build Process Automation

SAP Developers
Advanced

Architecture

SAP Build Process Automation is a multi-tenant BTP managed service. Processes are triggered from external systems, execute on the Build PA engine, route human tasks to the Work Zone Task Center, and call SAP backends via the Destination Service or directly through SAP Event Mesh.

SAP Build Process Automation — Platform Architecture
Rendering diagram…

Workflows

The Process Editor provides a visual BPMN-based canvas for designing workflows. Processes are composed of steps (form tasks, actions, automations, conditions, timers) connected by sequence flows and gateways (exclusive, parallel, inclusive).

Triggers

  • REST API trigger (external HTTP POST)
  • SAP Event Mesh — business event topics
  • SAP S/4HANA business events (BEF)
  • Schedule trigger (cron or one-time)
  • Start form — manual user-initiated

Gateways and Flow Control

  • Exclusive gateway (XOR) — first matching condition
  • Parallel gateway — split and join concurrent branches
  • Inclusive gateway — multiple matching paths
  • Timer event — wait until date/time or duration
  • Escalation event — SLA breach handling

Human Task (Form Step)

  • Recipient: static user, role, or formula expression
  • Form: linked Build PA form (drag-and-drop fields)
  • Due date: fixed duration or formula from context
  • Escalation: reassign or auto-approve on timeout
  • Priority: low / medium / high / very high

Action Step

  • Call REST API (BTP Destination or direct URL)
  • Call SAP S/4HANA OData action
  • Send email via SAP Alert Notification Service
  • Trigger child workflow (call process)
  • Update process context variables

Automation Activity (RPA)

  • Trigger desktop bot project on an agent machine
  • Pass input parameters from process context
  • Receive output variables back to process
  • Synchronous (wait) or asynchronous (fire-and-forget)
  • Error handling: retry count, fallback branch

Process Variables and Context

  • Context payload defined at trigger time (JSON)
  • Variables updated by action and form steps
  • Condition expressions reference context fields
  • Recipient formulas use context for dynamic routing
  • Full context available in all downstream steps

Process Trigger via REST API

trigger-po-approval.js — Start a Build PA process instance
1// Trigger a Build Process Automation workflow via REST API
2// POST /public/workflow/rest/v1/workflow-instances
3// Auth: OAuth2 client credentials (Build PA service instance binding)
4
5const axios = require('axios')
6
7async function triggerPOApprovalWorkflow(poData) {
8  // 1. Obtain an OAuth2 access token from XSUAA
9  const tokenResponse = await axios.post(
10    `${process.env.XSUAA_URL}/oauth/token`,
11    new URLSearchParams({
12      grant_type: 'client_credentials',
13      client_id: process.env.BPA_CLIENT_ID,
14      client_secret: process.env.BPA_CLIENT_SECRET,
15    }),
16    { headers: { 'Content-Type': 'application/x-www-form-urlencoded' } }
17  )
18  const accessToken = tokenResponse.data.access_token
19
20  // 2. Trigger the workflow instance
21  const response = await axios.post(
22    `${process.env.BPA_API_URL}/public/workflow/rest/v1/workflow-instances`,
23    {
24      // Process definition ID — set in Build PA designer
25      definitionId: 'po-approval-workflow',
26
27      // Context payload — available as process variables in the workflow
28      context: {
29        purchaseOrderId: poData.id,
30        purchaseOrderNumber: poData.number,
31        amount: poData.totalAmount,
32        currency: poData.currency,
33        costCenter: poData.costCenter,
34        vendorName: poData.vendorName,
35        requestorEmail: poData.requestorEmail,
36        requestorName: poData.requestorName,
37        // ISO 8601 deadline for the entire process
38        processDeadline: new Date(Date.now() + 5 * 24 * 60 * 60 * 1000).toISOString(),
39      },
40    },
41    {
42      headers: {
43        Authorization: `Bearer ${accessToken}`,
44        'Content-Type': 'application/json',
45      },
46    }
47  )
48
49  // Returns { id, definitionId, status, startedAt, ... }
50  return response.data
51}
52
53module.exports = { triggerPOApprovalWorkflow }

Business Rules

The Business Rules editor provides a visual interface for building decision logic without code. Rules are encapsulated as Rule Services — versioned, callable from within a process (Decision step) or via a standalone REST API. Business experts can maintain rule tables without developer involvement.

Rule Service Components

  • Data Object: Input and output schema (structured type with fields). Defines what goes into and comes out of the rule service.
  • Rule: A single decision unit — either a Decision Table (tabular rows of if/then conditions) or a Text Rule (natural language expression).
  • Rule Set: A named collection of rules evaluated together. Supports different hit policies: first match, all matches, unique.
  • Rule Service: The deployable unit — bundles one or more rule sets, exposes a versioned REST API, and is consumed from processes or external callers.

Decision Table — Hit Policies

  • First: Evaluate rows top-to-bottom; return the first matching row. Standard for routing and approval logic.
  • Unique: Exactly one row must match; throw an error if multiple rows match. Good for exclusivity enforcement.
  • Any: Return all matching rows as a collection. Used for multi-output decisions (e.g., list of approvers).
  • Rule Order: Return all matches in the order they appear in the table. Useful for sequential validation rules.
Business Rules — PO Approval Routing decision table (config representation)
1// SAP Build Process Automation — Business Rules
2// Decision table structure (represented as configuration data)
3// Defined visually in the Rules Editor; exported as rule service descriptor
4
5// ── Decision Table: PO Approval Routing ─────────────────────────────────────
6// Rule Service ID: po-approval-routing
7// Input parameters:  amount (Number), currency (String), costCenter (String)
8// Output parameters: approvalLevel (String), autoApprove (Boolean)
9
10// Rule table rows (evaluated top-to-bottom, first match wins):
11//
12// | amount    | currency | costCenter   | approvalLevel | autoApprove |
13// |-----------|----------|--------------|---------------|-------------|
14// | <= 1000   | EUR      | *            | "NONE"        | true        |
15// | <= 5000   | EUR      | *            | "MANAGER"     | false       |
16// | <= 25000  | EUR      | CC-FINANCE   | "MANAGER"     | false       |
17// | <= 25000  | EUR      | *            | "CFO"         | false       |
18// | > 25000   | EUR      | *            | "BOARD"       | false       |
19// | *         | USD      | *            | "CFO"         | false       |
20
21// ── Invoking the Rule Service from a Process ─────────────────────────────────
22// In the Process Editor, add a "Decision" step and configure:
23//   Rule Service: po-approval-routing
24//   Input mapping:
25//     amount     → process variable: context.amount
26//     currency   → process variable: context.currency
27//     costCenter → process variable: context.costCenter
28//   Output mapping:
29//     approvalLevel → process variable: routing.approvalLevel
30//     autoApprove   → process variable: routing.autoApprove
31
32// ── Calling the Rule Service via REST API ────────────────────────────────────
33// POST /rest/v2/rule-services/po-approval-routing/versions/1.0.0
34{
35  "RuleServices": [
36    {
37      "__name__": "po-approval-routing",
38      "__type__": "RuleService",
39      "amount": 12000,
40      "currency": "EUR",
41      "costCenter": "CC-1234"
42    }
43  ]
44}
45// Response:
46// {
47//   "Result": [{ "approvalLevel": "CFO", "autoApprove": false }]
48// }

Forms

The Forms editor provides a drag-and-drop canvas for building the UI presented to users in their Task Center inbox. Forms are linked to specific process steps (human tasks) and read from or write to process context variables. Both Start Forms (to trigger a process manually) andApproval Forms (at human task steps) are built with the same editor.

Input Fields

  • Text
  • Number
  • Date
  • Dropdown (static list)
  • Checkbox
  • Text area

Display Fields

  • Read-only text (from context)
  • Table (from array context)
  • Header
  • Paragraph
  • Separator

Action Buttons

  • Approve / Reject (built-in)
  • Custom action labels
  • Conditional visibility
  • Required field validation
  • Confirmation dialog

Form Bindings

  • Bind to process context variable
  • Write back on submission
  • Computed default from context
  • Conditional field visibility
  • Validation formulas
Forms in Work Zone Task Center
Approval forms are rendered directly in the SAP Build Work Zone Task Center. Users see the process context (read-only fields showing what they are approving) and the action fields they need to fill in. The Task Center also renders tasks from S/4HANA Flexible Workflow, SuccessFactors, Ariba, and Concur — making it the single interface for all pending approvals across the SAP landscape.

Process Visibility

Process Visibility is the monitoring and analytics layer of SAP Build Process Automation. It provides real-time dashboards, SLA tracking, and instance-level audit trails for all running and completed process instances.

Process Workspace

Pre-built dashboard for each process definition showing: active instances, completed, failed, average cycle time, SLA compliance rate. Configurable per process.

SLA Management

Define target duration for processes and individual steps. Dashboards show on-time vs. overdue percentages. Escalation events trigger automatically on breach.

Instance-Level Audit Trail

Per-instance timeline: who acted, what decision was made, when. Full context variable history. Exportable for compliance and audit purposes.

Process Performance Indicators (PPIs)

Define custom KPIs — e.g., "% of POs approved within 24 hours". PPIs aggregate across all instances and display in the workspace dashboard.

Error and Retry Management

Failed process steps visible in the Monitoring view. Admins can retry failed action steps (e.g., a backend API call that timed out) without restarting the instance.

Task Inbox Analytics

Per-approver workload reports: tasks pending, average response time, escalations received. Useful for identifying bottlenecks and rebalancing task assignments.

Automation — RPA Bots

The RPA capability in SAP Build Process Automation enables automation of repetitive desktop tasks — particularly legacy system interactions (SAP GUI T-codes, Excel data processing, web scraping) that cannot be reached through APIs. Bots are built visually with a low-code automation editor or a screen recorder, then executed on Windows machines running the Build PA Desktop Agent.

SAP Build Process Automation — RPA Bot Architecture
Rendering diagram…

Attended vs Unattended Bots

Attended Bot

Runs on the user's own machine while the user is logged in. The user initiates the bot (e.g., via a Build Apps button or a keyboard shortcut). The bot assists the user with repetitive tasks — auto-filling forms, extracting data from one screen, pasting into another. Useful for desktop tasks that require human judgement at certain steps.

Unattended Bot

Runs on a dedicated server machine without any user present. Triggered by a Build PA process step, a schedule, or an API call. Used for high-volume batch processing — invoice posting, master data extraction, report generation. Requires a dedicated Windows Server VM with the Desktop Agent installed as a Windows service.

Desktop Agent Setup

  1. 1Install Build PA Desktop Agent on target Windows machine (requires Windows 10/11 or Windows Server 2019/2022)
  2. 2Register the agent in Build PA cockpit — generates a registration token
  3. 3Agent connects to Build PA service via secure WebSocket (no inbound firewall ports required)
  4. 4Assign bot projects to the registered agent or agent pool
  5. 5Configure execution environment: screen resolution, user account for unattended mode
  6. 6Monitor agent status and bot run logs in Build PA Monitoring view

SAP GUI Automation

Automate legacy SAP T-code screens — open transactions, fill fields, execute, read results. Supports scripting of complex multi-screen workflows in ECC and S/4HANA on-premise.

Microsoft Excel Automation

Read from and write to Excel files — used for mass data extraction from SAP (copy-paste via GUI) and formatted report generation. Also handles formula evaluation and cell formatting.

Web Application Automation

Automate browser-based applications — form filling, table scraping, button clicking, status checking. Works with Chromium-based browsers. Selectors based on DOM attributes.

Microsoft Outlook Automation

Parse incoming emails by subject/sender pattern, extract attachments, classify and forward to queues, or trigger Build PA workflows based on email content.

Pre-built Content Packages

SAP provides a library of pre-built automation projects in the SAP Business Accelerator Hub — e.g., Sales Order processing, Invoice AP, Master Data extraction. Reuse and extend rather than build from scratch.

Bot Recorder

Record desktop actions step-by-step; the recorder generates the automation project automatically. Reduces development time significantly for standard UI interaction patterns.

SAP S/4HANA Integration

SAP Build Process Automation integrates with SAP S/4HANA in two directions: S/4HANA pushes business events via SAP Event Mesh to trigger workflows, and Build PA calls back to S/4HANA APIs to execute decisions (approve, reject, update).

S/4HANA Business Events — event topic subscription and payload (config reference)
1# SAP S/4HANA Business Events — subscription for Build PA trigger
2# Configured in: SAP S/4HANA Cloud → Settings → Event Topics
3
4# Step 1: Create a channel in SAP Event Broker / SAP Event Mesh on BTP
5#   Channel type: SAP S/4HANA Cloud Private / Public Edition
6
7# Step 2: Subscribe to S/4HANA business event topics
8#   Topic pattern (public cloud): sap/s4/beh/purchaserequisition/v1/PurchaseRequisition/Created/v1
9#   Topic pattern (private cloud): sap/s4/beh/<namespace>/PurchaseRequisition/Created/v1
10
11# Step 3: Configure Build PA Event Trigger
12#   Trigger type: Event
13#   Queue name:   BPA_PO_APPROVAL_QUEUE
14#   Event topic:  sap/s4/beh/purchaserequisition/v1/PurchaseRequisition/Created/v1
15
16# ── Example S/4HANA Business Event Payload ───────────────────────────────────
17# {
18#   "specversion": "1.0",
19#   "type": "sap.s4.beh.purchaserequisition.v1.PurchaseRequisition.Created.v1",
20#   "source": "/default/sap.s4.beh/PROD",
21#   "id": "6c2ef5d3-7a4b-4f9e-b123-a1b2c3d4e5f6",
22#   "time": "2025-06-04T10:30:00Z",
23#   "datacontenttype": "application/json",
24#   "data": {
25#     "PurchaseRequisition": "0010001234",
26#     "PurchaseRequisitionType": "NB"
27#   }
28# }
29
30# Step 4: Map event payload to process context variables in Build PA designer
31#   data.PurchaseRequisition  → context.purchaseRequisitionId
32#   data.PurchaseRequisitionType → context.docType
33
34# ── Outbound S/4HANA API Call (from process action step) ─────────────────────
35# Configure a BTP Destination for S/4HANA in Build PA action:
36#   Destination name: S4HANA_CLOUD_PP
37#   Service:          SAP S/4HANA Cloud
38#   Auth:             OAuth2SAMLBearerAssertion (principal propagation)
39#   OData endpoint:   /sap/opu/odata4/sap/api_purchaserequisition_2/srvd_a2x/
40#                     sap/api_purchaserequisition_2/0001/A_PurchaseRequisition

S/4HANA → Build PA (Event-driven)

  • S/4HANA publishes business events to SAP Event Mesh queue (BEF — Business Event Framework)
  • Build PA Event Trigger subscribes to the queue and starts a process instance per event
  • Event payload mapped to process context variables in the Process Editor
  • Supported in S/4HANA Cloud Public Edition (standard API) and Private Edition (configurable)
  • Pre-built content packages available for Purchase Requisition, Sales Order, FI posting events

Build PA → S/4HANA (Action Steps)

  • Action step calls S/4HANA OData V4 API (standard or custom) via BTP Destination
  • Authentication: OAuth2 SAML Bearer Assertion (principal propagation) or client credentials
  • Typical actions: approve / reject purchase order, create goods receipt, release invoice
  • Error handling: retry on timeout, escalate on persistent failure
  • Notification step: send email to requestor via SAP Alert Notification Service on completion

SAP CAP Integration

SAP CAP services trigger and receive callbacks from SAP Build Process Automation via REST. CAP connects to Build PA through a BTP Destination configured with client credentials, keeping the authentication server-side.

srv/po-approval-service.js — CAP handler triggering Build PA + receiving callback
1// SAP CAP — Trigger Build Process Automation from a CAP service event handler
2// Pattern: after a purchase order is confirmed, initiate the approval workflow
3
4const cds = require('@sap/cds')
5
6module.exports = cds.service.impl(async function () {
7  const { PurchaseOrders } = this.entities
8
9  // ── After a new PO is submitted, trigger the approval workflow ──────────────
10  this.after('submitForApproval', PurchaseOrders, async (result, req) => {
11    const po = result
12
13    // Retrieve the Build PA destination (configured in BTP Destination Service)
14    const bpa = await cds.connect.to('BUILD_PROCESS_AUTOMATION')
15
16    try {
17      const instance = await bpa.send({
18        method: 'POST',
19        path: '/public/workflow/rest/v1/workflow-instances',
20        data: {
21          definitionId: 'po-approval-workflow',
22          context: {
23            purchaseOrderId: po.ID,
24            purchaseOrderNumber: po.externalNumber,
25            amount: po.totalAmount,
26            currency: po.currency,
27            costCenter: po.costCenter,
28            vendorName: po.vendor_Name,
29            requestorEmail: req.user.id,
30            requestorName: req.user.attr?.name ?? req.user.id,
31          },
32        },
33      })
34
35      // Store the workflow instance ID on the PO for status tracking
36      await UPDATE(PurchaseOrders, po.ID).with({
37        workflowInstanceId: instance.id,
38        approvalStatus: 'PENDING',
39      })
40
41      req.info(`Approval workflow started: ${instance.id}`)
42    } catch (err) {
43      // Log but do not fail the CAP request — workflow start is async
44      req.warn(`Could not start approval workflow: ${err.message}`)
45    }
46  })
47
48  // ── Webhook: receive workflow completion callback ───────────────────────────
49  // Register a Build PA webhook pointing to this CAP service endpoint
50  // POST /odata/v4/procurement/receiveApprovalResult
51  this.on('receiveApprovalResult', async (req) => {
52    const { purchaseOrderId, decision, decidedBy, comment } = req.data
53
54    await UPDATE(PurchaseOrders, purchaseOrderId).with({
55      approvalStatus: decision === 'APPROVED' ? 'APPROVED' : 'REJECTED',
56      approvedBy: decidedBy,
57      approvalComment: comment,
58      approvalDate: new Date().toISOString(),
59    })
60
61    return { status: 'acknowledged' }
62  })
63})

Trigger Pattern

From a CAP after-handler or action, call the Build PA REST API to start a process instance. Store the returned instance ID on the entity for status tracking.

Callback / Webhook Pattern

Register a Build PA action step to POST to a CAP OData action endpoint on process completion or state change. CAP handles the callback and updates the entity.

BTP Destination

Configure a BTP Destination of type HTTP with OAuth2 Client Credentials pointing to the Build PA service instance URL. Reference by name in cds.connect.to().

cds.env.requires

Declare the Build PA service binding in package.json under cds.requires, mapping to the BTP service instance. Enables portable, environment-agnostic configuration.

Event-driven with Event Mesh

Alternatively, CAP publishes domain events to SAP Event Mesh. Build PA subscribes to those events and triggers processes without a direct HTTP call from CAP.

Error Handling

Wrap the trigger call in try/catch. Process triggering should not block the main CAP transaction — emit an info message on failure and let the operator retry manually.

SAP Build Work Zone — Task Center Integration

All human task steps in Build PA workflows are surfaced in the SAP Build Work Zone Task Center — the unified inbox for approvals and actions across the SAP application landscape. Task Center aggregates tasks from multiple sources, so users have a single place for all pending work.

SAP Build Work Zone Task Center — Unified Inbox Architecture
Rendering diagram…

Task Center Configuration

  1. 1Enable Task Center in the Work Zone Advanced Edition subaccount
  2. 2Configure provider connection: SAP Build Process Automation → Task Center connector in Work Zone admin console
  3. 3Assign the "TaskCenter.Admin" role collection to administrators
  4. 4Configure principal propagation: IAS trust between BTP and the S/4HANA / SuccessFactors tenants
  5. 5Verify task pull frequency (default: 5 minutes; configurable per provider)
  6. 6Test: assign a task in Build PA and verify it appears in the Work Zone Task Center within the polling window

Task Center Capabilities

  • Unified viewAll task sources shown in one list with provider tag
  • Filter and sortFilter by source, status, priority, due date; sort by creation date
  • SearchFull-text search across task subjects from all providers
  • Inline approvalApprove or reject directly from the list (quick actions)
  • Detail viewOpen form UI for tasks requiring additional input fields
  • Mobile via SAP Mobile StartAll Task Center tasks accessible on iOS and Android
  • Teams integrationTask notifications forwarded to Microsoft Teams channel
  • DelegationOut-of-office substitute can receive delegated tasks

Workflow Examples

The following three workflows represent common production patterns. Each uses standard Build PA capabilities and documented SAP API Business Hub services.

Procurement: Purchase Order Approval

Multi-level approval with auto-approval below threshold and S/4HANA write-back

Procurement Workflow — Purchase Order Approval with Business Rules
Rendering diagram…
Trigger

S/4HANA Business Event — PurchaseRequisition Created (BEF)

Auto-approval rule

Amount ≤ 5,000 EUR — approved automatically via decision table

Manager approval

Form task — amount > 5,000 EUR. 48-hour SLA with escalation.

CFO approval

Form task — amount > 25,000 EUR. 72-hour SLA. Requires manager approval first.

Approval action

OData PATCH to A_PurchaseRequisition — releases the PR in S/4HANA

Notification

SAP Alert Notification Service email to requestor on approve/reject

trigger-po-approval.js — Trigger procurement workflow from Node.js
1// Trigger a Build Process Automation workflow via REST API
2// POST /public/workflow/rest/v1/workflow-instances
3// Auth: OAuth2 client credentials (Build PA service instance binding)
4
5const axios = require('axios')
6
7async function triggerPOApprovalWorkflow(poData) {
8  // 1. Obtain an OAuth2 access token from XSUAA
9  const tokenResponse = await axios.post(
10    `${process.env.XSUAA_URL}/oauth/token`,
11    new URLSearchParams({
12      grant_type: 'client_credentials',
13      client_id: process.env.BPA_CLIENT_ID,
14      client_secret: process.env.BPA_CLIENT_SECRET,
15    }),
16    { headers: { 'Content-Type': 'application/x-www-form-urlencoded' } }
17  )
18  const accessToken = tokenResponse.data.access_token
19
20  // 2. Trigger the workflow instance
21  const response = await axios.post(
22    `${process.env.BPA_API_URL}/public/workflow/rest/v1/workflow-instances`,
23    {
24      // Process definition ID — set in Build PA designer
25      definitionId: 'po-approval-workflow',
26
27      // Context payload — available as process variables in the workflow
28      context: {
29        purchaseOrderId: poData.id,
30        purchaseOrderNumber: poData.number,
31        amount: poData.totalAmount,
32        currency: poData.currency,
33        costCenter: poData.costCenter,
34        vendorName: poData.vendorName,
35        requestorEmail: poData.requestorEmail,
36        requestorName: poData.requestorName,
37        // ISO 8601 deadline for the entire process
38        processDeadline: new Date(Date.now() + 5 * 24 * 60 * 60 * 1000).toISOString(),
39      },
40    },
41    {
42      headers: {
43        Authorization: `Bearer ${accessToken}`,
44        'Content-Type': 'application/json',
45      },
46    }
47  )
48
49  // Returns { id, definitionId, status, startedAt, ... }
50  return response.data
51}
52
53module.exports = { triggerPOApprovalWorkflow }

HR: Employee Onboarding

Parallel onboarding tracks — IT, Security, and Facilities — with a synchronised join before start date

Trigger

SuccessFactors New Hire event via SAP Event Mesh (or manual Start Form by HR business partner)

Parallel gateway

3 concurrent tracks start simultaneously: IT Setup, Access Provisioning, Equipment Order

IT Setup task

Form task to IT team — laptop spec, software list, VPN access. Due: 3 business days before start date.

Access Provisioning task

Form task to Security team — SAP role assignments, AD group membership, system access list.

Equipment Order task

Form task to Facilities — desk, phone, equipment. Due: 5 business days before start date.

Join gateway

All 3 tracks complete → Manager Welcome Meeting form task. Auto-complete if overdue. Welcome email sent to new hire.

hr-onboarding-workflow.js — HR workflow structure and context
1// HR Onboarding Workflow — trigger from SuccessFactors New Hire event
2// Build PA process: hr-onboarding-workflow
3
4// ── Process context variables ─────────────────────────────────────────────────
5const onboardingContext = {
6  employeeId: 'EMP-20250604-001',
7  firstName: 'Jane',
8  lastName: 'Smith',
9  startDate: '2025-07-01',
10  department: 'Engineering',
11  costCenter: 'CC-ENG-001',
12  officeLocation: 'Dubai',
13  jobTitle: 'Senior Developer',
14  managerEmail: 'ahmed.hassan@company.com',
15  hrbpEmail: 'hr-bp@company.com',
16  // Parallel track assignments (set by process, populated by approvers)
17  itSetupAssignee: null,
18  accessProvisioningAssignee: null,
19  equipmentOrderAssignee: null,
20}
21
22// ── Parallel Gateway — three simultaneous onboarding tracks ─────────────────
23// Track 1 — IT Setup (form task assigned to IT team)
24//   Form fields: laptop type, software list, VPN access required (Y/N)
25//   Recipient:   Role "IT_ONBOARDING_TEAM" (resolved at runtime)
26//   Due:         3 business days before startDate
27
28// Track 2 — Access Provisioning (form task assigned to Security team)
29//   Form fields: system access list, SAP roles required, AD group assignment
30//   Recipient:   Role "SECURITY_ACCESS_TEAM"
31//   Due:         3 business days before startDate
32
33// Track 3 — Equipment Order (form task assigned to Facilities team)
34//   Form fields: desk location, phone extension, equipment list
35//   Recipient:   Role "FACILITIES_TEAM"
36//   Due:         5 business days before startDate
37
38// ── Joining Gateway — all 3 tracks complete ───────────────────────────────────
39// Manager Welcome Meeting scheduling form
40//   Recipient: managerEmail
41//   Auto-complete if not done within 1 business day of start date
42
43// ── End — send welcome email to new hire ─────────────────────────────────────
44//   Action step: call SAP Alert Notification Service
45//   Template: onboarding-welcome-email
46//   Recipients: [employeeId, managerEmail, hrbpEmail]

IT: Change Request Automation

CAB approval with automated RPA bot execution, pre-change checks, timer-gated deployment, and post-change verification

Trigger

Start Form submitted by IT engineer — change type, impact level, target system, scheduled window

Approval routing

Decision table: STANDARD/LOW → auto-approve; NORMAL/MEDIUM → peer review; NORMAL/HIGH → CAB; EMERGENCY → Emergency CAB

CAB approval task

Multi-approver form task — CAB_MEMBER role. Configurable voting: majority / unanimous. 5-business-day SLA.

Pre-change RPA bot

Unattended bot: checks target system state, verifies backup, captures baseline config snapshot.

Timer gate

Process waits until the scheduled change window (context.scheduledWindow) using a timer event.

Change + verification bots

Unattended bots execute the change steps and run post-change tests. Results passed back to process context.

it-change-request-workflow.js — IT workflow structure with RPA bot steps
1// IT Change Request Workflow — CAB approval + automated bot execution
2// Build PA process: it-change-request-workflow
3
4// ── Process flow overview (pseudo-code representation) ────────────────────────
5
6// START: IT engineer submits change request via Start Form
7//   context.changeId, changeTitle, changeType, impactLevel,
8//   targetSystem, scheduledWindow, rollbackPlan
9
10// STEP 1 — Business Rule: determine approval path
11//   Rule input:  changeType (STANDARD | NORMAL | EMERGENCY), impactLevel (LOW | MEDIUM | HIGH)
12//   Rule output: approvalPath (AUTO | PEER | CAB | EMERGENCY_CAB)
13
14// STEP 2 — Condition gateway on approvalPath:
15//   → AUTO:          skip to pre-approved implementation
16//   → PEER:          assign peer review form task (1 approver, 24h SLA)
17//   → CAB:           assign CAB form task (3 approvers, majority vote, 5d SLA)
18//   → EMERGENCY_CAB: assign emergency CAB task (2 approvers, 4h SLA)
19
20// STEP 3 — CAB Approval Form Task
21//   Recipients:  members of Role "CAB_MEMBER" (resolved dynamically)
22//   Voting:      configurable: unanimous / majority / any
23//   Form fields: recommendation (APPROVE | REJECT | DEFER), comment, conditions
24
25// STEP 4 — Condition: approved?
26//   → Rejected: notify requester, update ITSM ticket, END
27//   → Approved: proceed to implementation
28
29// STEP 5 — Automation Activity: RPA Bot — pre-change checks
30//   Bot project: it-change-prechecks-bot
31//   Inputs:      targetSystem, changeId
32//   Actions:     capture system state, verify backup status, validate config
33//   Outputs:     checksPassedFlag, checksReport
34
35// STEP 6 — Condition: pre-checks passed?
36//   → Failed: notify CAB, escalate, END
37//   → Passed: proceed
38
39// STEP 7 — Timer: wait until scheduledWindow start
40//   Timer type: specific date/time from context.scheduledWindow
41
42// STEP 8 — Automation Activity: RPA Bot — execute change
43//   Bot project:   it-change-execution-bot
44//   Inputs:        targetSystem, changeId, changeType
45//   Actions:       execute scripted change steps, log each action
46//   Outputs:       executionStatus, executionLog
47
48// STEP 9 — Automation Activity: RPA Bot — post-change verification
49//   Bot project: it-change-verification-bot
50//   Outputs:     verificationStatus, testResults
51
52// STEP 10 — Notify stakeholders and close ITSM ticket
53//   Action: call Integration Suite iFlow → update ServiceNow / Solution Manager

Licensing

Status:Generally AvailablePlannedRoadmapFuture Direction
Build

Build Process Automation

Generally Available· GA

Combines workflow automation and robotic process automation (RPA) in one SAP BTP service — enabling end-to-end process automation with pre-built SAP content packages.

CPEASubscriptionGROW
WorkflowsBots

Workflow automation instances consumed via CPEA credits. RPA bots (attended/unattended) carry separate licensing. Included in GROW with SAP.

GROW with SAPSAP Build Suite
Build

Build Apps

Generally Available· GA

SAP's visual, no-code/low-code application development tool for building responsive web and mobile applications without hand-coding.

SubscriptionRISEGROW
Active Users

Licensed per active user per month. Included with GROW with SAP (limited). Available as stand-alone subscription.

GROW with SAPSAP Build Suite
Build

Work Zone

Generally Available· GA — Standard edition included in RISE/GROW; Advanced edition separate

A central digital workplace hub — providing a unified launchpad for SAP and non-SAP applications, personalised workpages, notifications, and workflow management.

RISEGROWSubscription
Active Users

Standard edition included. Advanced edition licensed per active user — requires separate CPEA/BTPEA allocation.

RISE with SAPGROW with SAP

Build Process Automation — Edition Comparison

SAP Build Process Automation — Capability Matrix by License

Capability
Free TierTrial / sandbox onlyGenerally Available
GROW with SAPIncluded entitlementGenerally Available
Standard (CPEA)Workflow automationGenerally Available
Standard + RPAWorkflows + botsGenerally Available
Workflow Automation
Visual process editor (BPMN-based)
Human approval tasks (form steps)
Business rules (decision tables)
Pre-built SAP content packages
Work Zone Task Center integration
S/4HANA Business Event triggers
Process Visibility dashboards
Unlimited workflow instancesQuotaCPEA creditsCPEA credits
RPA — Robotic Process Automation
Desktop Agent (Windows machine)
Attended bots (user-initiated)
Unattended bots (scheduled / process-triggered)
Bot Recorder (auto-generate from screen recording)
Pre-built RPA content packages
Bot scheduling and monitoring
CPEA Consumption Model for Workflows
Workflow automation instances in Build PA (Standard tier) are consumed via CPEA (Cloud Platform Enterprise Agreement) credits. Each workflow instance consumes credits based on the number of active participants and the process duration. RPA bots are licensed separately per bot (attended or unattended) per month — they are not consumed via CPEA credits. The GROW with SAP entitlement includes a limited quota of workflow instances; contact your SAP account executive for the specific quota applicable to your contract.

Road Map & Recent Updates

Source: SAP Road Map Explorer (roadmaps.sap.com) and SAP Sapphire 2025 announcements. Items below reflect publicly disclosed plans as of mid-2025.

Status:Generally AvailablePlannedRoadmapFuture Direction
Generally Available

Generally Available

  • BPMN-based visual process editor with human and automation steps
  • Decision tables and rule services (Business Rules editor)
  • Forms editor with context variable binding
  • Work Zone Task Center integration (provider connector)
  • S/4HANA Business Event Framework trigger
  • Process Visibility dashboards and SLA tracking
  • Desktop Agent with attended and unattended bots
  • Pre-built content packages (SAP Business Accelerator Hub)
  • CAP and REST API trigger integration
Planned

Planned Enhancements

  • Enhanced Process Visibility with AI-generated bottleneck insights
  • Improved mobile experience for form tasks in SAP Mobile Start
  • Additional pre-built content packages for finance and logistics
  • Expanded SAP Event Mesh topic coverage for S/4HANA events
  • Simplified agent pool management for unattended bot fleets
Roadmap

Roadmap Items

  • AI-assisted process generation from natural language description
  • Joule integration within Build PA — describe steps, get a process draft
  • Deeper integration with SAP Build Apps — trigger workflows directly from app logic
  • Cross-process visibility — unified dashboards spanning multiple process definitions
  • AI-powered anomaly detection in process execution (SLA breach prediction)
Future Direction

Future Direction

  • Agentic AI integration — Joule agents as autonomous process participants
  • Unified Build Apps + Build PA designer surface for embedded app-process combos
  • Event-driven process mesh — multi-system process choreography via Event Mesh
  • AI-driven automatic bot generation from process recording

Best Practices

Use business rules for approval routing — never hardcode in the process

Process conditions that change over time (approval thresholds, cost centre overrides, currency rules) belong in decision tables, not in hardcoded gateway conditions. Business users can update rule tables in the Rules Editor without a process redeployment.

Secure process context — never store passwords in variables

Process context variables are visible to approvers and in audit logs. Never store credentials, API keys, or personal data beyond what is strictly required for the approval decision. Use BTP Destination Service credentials for backend calls — they are resolved server-side.

Always define SLAs and escalations on human task steps

Human tasks without a due date will sit in the inbox indefinitely if the approver is absent. Set a due date formula on every form step and configure an escalation action (reassign or auto-approve) so the process cannot be blocked indefinitely.

Prefer APIs over RPA bots where available

RPA bots are brittle — they break when the target application UI changes. Use SAP OData APIs or Integration Suite iFlows for S/4HANA interactions. Reserve bots for genuine legacy systems (SAP GUI on-premise, Excel, non-API applications) where no API exists.

Design processes to be resumable on transient errors

Action steps that call external APIs may fail transiently (timeout, network blip). Configure a retry count (2–3 retries, exponential back-off) and a fallback escalation branch. Do not let a transient API failure abort an approval flow that has already passed human steps.

Start with SAP pre-built content packages

SAP provides pre-built workflow templates and bot projects in the SAP Business Accelerator Hub for common scenarios (PO approval, invoice AP, leave request). Import and adapt these rather than building from scratch — they incorporate SAP best practices and tested API mappings.

Keep individual processes single-purpose

Avoid building one mega-process that handles all approval scenarios via complex conditions. Split into focused, reusable processes (PO approval, goods receipt confirmation, invoice approval) that can be independently versioned, monitored, and maintained.

Configure Process Visibility workspaces from the start

Process Visibility must be configured before instances start — it does not retroactively collect data. Define tracking indicators (instance count, average cycle time, SLA compliance) before the process goes to production.

Common Pitfalls

No SLA on human task steps

Form steps without a due date block forever if an approver is on leave or ignores the task. Always set a due date and configure an escalation (reassign or auto-approve).

Hardcoded routing thresholds

Embedding approval amounts (e.g., "> 10000 EUR") directly in process gateway conditions means a process redeployment every time thresholds change. Use a decision table in Business Rules instead.

Task Center not displaying tasks

Tasks only appear in Task Center after the principal propagation trust is established between Build PA and Work Zone. Missing IAS trust or missing "TaskCenter.Admin" role collection assignment are the two most common causes.

Desktop Agent not registered or offline

Automation Activity steps fail silently if the Desktop Agent machine is offline or unregistered. Monitor agent status in Build PA Monitoring. Configure alerts for agent disconnection via SAP Alert Notification.

Process Visibility configured after instances start

Visibility workspaces only collect data from instances started after the workspace is activated. Data for instances started before configuration cannot be backfilled. Enable visibility before go-live.

Redeploying a process with active instances

Deploying a new version of a process does not migrate existing instances to the new version. Active instances continue on the old version. Plan version upgrades carefully — especially for long-running approval workflows.

SAP References