SAP Build Process Automation is SAP’s low-code automation service on SAP Business Technology Platform. You get workflow for moving work between people. Bots for the screens nobody ever built an API for. Rules tables underneath, and forms wherever somebody still has to read a figure and decide. Anyone who knows how a process really runs can wire one up without going near a developer. SAP built it in 2022 out of two products it already had, Workflow Management and Intelligent RPA, and since January 2026 it has carried AI agents too.

Somebody in finance is chasing the same approval over email for the third time this week. Somebody in procurement rekeys the same vendor record into two systems every Tuesday morning. In HR there is a spreadsheet that gets emailed around on the last Friday of the month and nobody can remember who built it. None of it is broken badly enough to get a development budget. So none of it gets fixed. Between them those three jobs take maybe four hours a week, and they have been taking them for years.

SAP Build Process Automation is aimed at exactly that tier of work. What follows covers what is actually inside the product and what teams tend to build with it first. Then how it sits on BTP, beside your core rather than in it. Then 2026, when agents arrived and changed how these things get designed. Most of the material still ranking for this topic was published before that happened.

What is SAP Build Process Automation?

SAP Build Process Automation is SAP’s low-code automation service, and it lives on SAP Business Technology Platform.

You get four fairly distinct things under one subscription. The process itself gets designed on a canvas where you drag boxes around and join them up. For the systems nobody ever built a decent API for, there are bots that work the screens the way a person would. Same five fields, same order, every time. Business rules move out of custom code and into tables, which tends to come as a relief to whoever inherited that code. And forms cover the points where somebody still has to read a figure and make a call on it, which is most processes at least once.

Those used to be separate products. SAP Workflow Management covered the process side. SAP Intelligent RPA covered the bots. Running two tools for one job never made much sense, so SAP merged them in 2022. You will still meet both old names, though. They sit in SAP notes written before the merge, and in whatever internal wiki page somebody put together in 2021 and never went back to.

Who actually builds things in it?

SAP will tell you business users, and that holds up to a point. Give a finance process owner the prebuilt approval content and they will have something running by the end of the week, no help needed. It stops holding up around the first custom Z table, or the authorisation object that behaves differently in quality than it does in dev, or the vendor portal that logs you out every twenty minutes. On most projects I have watched, the business owns the design and somebody from the technical side quietly sorts out the plumbing behind them.

What can you build with it?

Six pieces, although a first project usually touches three of them and leaves the rest alone until somebody asks for a dashboard.

Process builder

This is the canvas, and it looks roughly like the flowchart somebody already drew on a whiteboard when the process was first argued about. You drop in an approval step. You hang a condition off it for cases over 50,000. You point one branch at S/4HANA and the other at whoever handles exceptions. Then you keep going until the picture on screen matches what the process does on a bad week, not a good one. People who have never opened a developer tool in their life get on with it fine.

Automations, or bots

This is the RPA half, and it earns its keep on the jobs where no integration exists. Logging into a supplier portal every morning to pull yesterday’s numbers. Fetching a file somebody drops on a shared drive at an unpredictable hour. Copying figures out of one screen and into another when the two systems have never been introduced. It is dull work, which is exactly why handing it to a bot tends to be the first thing anyone notices.

Decisions

Your business rules get written as tables, in language somebody in finance can read without a translator. Approval limits are the usual example. When the threshold goes from 5,000 to 10,000 because the budget changed, somebody edits a row that afternoon. The alternative, which plenty of SAP shops are still living with, is a change request against custom code and a wait of several weeks.

Forms

Somewhere in most processes a person has to actually look at something and decide. Approvals, obviously, but also the exceptions nobody could write a rule for. These forms work on a phone. That sounds like a detail until you notice who is holding up your approvals. Usually the people who spend half the month in airports.

Process visibility

You get dashboards showing where things are stuck and how long each step really takes, which is almost never how long everyone assumed it took. Teams skip this during the build. When you are fighting to get something live it reads like a nice-to-have. Then a quarter goes by and somebody in a leadership meeting asks why invoice approvals average nine days. This is the only place that can answer that.

The store and prebuilt content

SAP keeps a library of packaged processes and bots you can pull in and bend to fit. This matters most on a first project, when somebody wants to see something working before the next steering committee. Three weeks, say. Starting from content that already runs beats starting from an empty canvas by a wide margin.

How does SAP Build Process Automation work?

Everything runs as a service on SAP BTP, which shapes the whole picture. You design in a browser. Your connections to other systems run through BTP destinations, which keeps credentials and endpoints in one place instead of scattered across four projects and somebody’s spreadsheet. When you deploy, you push to a runtime SAP operates. Nobody stands up a server.

The part that matters architecturally is where the automation physically runs. It sits beside S/4HANA rather than inside it, so nothing in the core gets modified, no Z object gets added and no standard transaction gets enhanced. That is what SAP’s Clean Core guidance asks for. The payoff shows up at your next upgrade. The regression list is short, because there is nothing of yours sitting in the core to regress. If a wider move is on the table at the same time, we go through the thinking in our guide to moving to a clean core.

Is it RPA, workflow, or both?

Both. Two separate products got folded into this one back in 2022, and people still arrive expecting one or the other, usually whichever half their last vendor conversation happened to cover.

On a live project the labour divides itself fairly quickly. Workflow takes a requisition from the person raising it to the person approving it and on into S/4HANA, since all three of those ends can hold a proper conversation. The supplier portal and the legacy warehouse screen cannot, so you point bots at those. Underneath, rules tables settle what should happen at each threshold. Agents are the newest part and they work out their own next move instead of walking a route somebody drew for them in advance.

One caveat before you lean on the bots. Your vendor will redesign their portal at some point, almost certainly without telling anybody, and your bot will stop working on the Monday after they do it. Point it at the systems where no API exists at all. Resist it on the ones where an API does exist and the only obstacle is having to go and ask another team for help. Teams already running broader RPA Software tend to learn this the expensive way.

Where does it fit in the SAP Build family?

SAP Build is a family name rather than something you can buy on its own. Search for one of the four and you will get pages about the other three. They overlap at the edges, and that is deliberate.

They overlap at the edges and they are meant to. A process you automate here often needs a screen somebody can use, which is where SAP Build Apps comes in. Most teams use two of the four. Which two comes down to whether the process needs a screen of its own, or just an approval sitting in somebody’s inbox.

From automation to agents: what changed in 2026

This is the part where most of what you will read on the subject is now out of date.

Agent building got its first proper outing at TechEd towards the end of 2025. Agent Builder in Joule Studio then reached general availability in January 2026, and it now sits inside SAP Build alongside everything else described here. It got filed as one more line on a release note. Fair enough as a description of the announcement. Not much use as a description of what it does to the way you design a process.

Ordinary automation does what the diagram says. Step one, then step two, test the condition, on to step three. For a purchase requisition that arrives in the same shape every time, that is precisely what you want and anything cleverer is a liability. It comes apart on the exceptions nobody mapped. Or in the single case that wanders across four systems in an order the person who drew the diagram had no reason to imagine. An agent works from the situation in front of it rather than from the diagram. It picks an action, sees what comes back, picks the next one. Several steps deep, with nothing drawn in advance.

There are four reasons that behaves itself inside an enterprise instead of frightening your security team. Agents inherit SAP Cloud Identity Services and principal propagation. An agent acting for a clerk in accounts payable gets that clerk’s authorisations and not one object more. MCP connections, configured in BTP, let an agent reach past SAP into a ticketing system or a contract repository. An orchestrator agent can hand a piece of work down to a specialist sub-agent and collect the result. And human-in-the-loop is switched on by default wherever money or a contract is involved. The same intelligence turning up across SAP Business AI is now reaching into how automation itself gets built.

If you are putting a plan together for this year, I would not start at the agent’s end of it. Get two or three conventional automations into production and watch what happens to them once a month-end hits and the volume triples. That is when the awkward cases surface. None of them came up in the design workshop. An agent aimed at an exception you have already documented does considerably better than one aimed at where you suspect the exceptions probably live.

SAP Build Process Automation use cases by business function

The same handful of candidates come up almost everywhere, whatever the industry.

Finance

Invoice approvals that currently live in an email thread forty messages deep. Three-way matching where the exceptions get routed to whoever can resolve them instead of sitting in a queue nobody owns. The month-end data pull that somebody does by hand on the first working day, every month, and has done for six years. Finance tends to put together the easiest business case of any department. Somebody on the team can already tell you how many days invoice approval runs to. They can usually also tell you what that costs in early-payment discounts nobody got round to claiming.

Procurement

Purchase requisitions, where somebody has to go and change the approval thresholds every time the budget gets revisited. Supplier onboarding, which in practice means chasing documents out of people who reliably ignore the first two emails. And contract renewals, which at a worrying number of companies still depend on one person remembering a date.

HR

Onboarding is the one everybody names first, and for good reason. A new starter needs accounts raised, a laptop ordered, access granted in several systems, and a manager who has been told they are arriving on Monday. Offboarding gets a fraction of the attention. It deserves more. Access that is still open three months after somebody left turns up in the next audit as a finding.

Sales and master data

Quote approvals that fire once somebody discounts past an agreed percentage. Customer master creation, where two people type the same address into two systems and spell it two different ways. Credit checks that hold an order until a human has looked at it. Nobody puts master data on a slide at a kickoff. A year on, the duplicate-customer cleanup is usually the thing that gives back the most hours.

These pile up during an ERP transition. Old habits meet a new system, and nobody has had the time to go back and tidy up after. If a move is on your roadmap, our rundown of what to settle before migrating is a sensible companion to this.

How Accely helps you get started

Technology is rarely what sinks one of these projects. What sinks them is the choice of first process. Somebody picks one that cannot be finished inside a quarter. Or one that two departments both claim and neither will sign off. Or one that was already broken before anybody automated it, in which case automation simply made the wrong answer arrive sooner.

Accely is an SAP Gold Partner, 26 years into enterprise SAP work, with north of 1,000 referenceable clients behind us. We start by working out which of your processes are worth the effort, and that list is usually shorter than people are expecting to hear. Then we build them with your team sitting alongside us rather than watching from a distance, so that whatever we learn stays in your building after the engagement closes. Agents go in where the process genuinely throws exceptions. On the ones that run the same way every time we will say so, and build an ordinary workflow instead. Cheaper to build. Breaks less often.

Think AI-First. Build What’s Next. Powered by Eerly AI Studio™.