The five decisions before the build
Each of these is a business decision with a technical consequence. None of them belongs to the developer, and all five need an answer before anyone models a process in SAP Build Process Automation.
Decision one: where the approval hierarchy comes from
There is always more than one candidate. HR holds a reporting line. The ERP system holds cost centre owners. A spreadsheet holds the delegation of authority matrix. Identity holds groups. These four rarely agree.
Pick one as the source of truth and make the others follow it. The usual answer for a delegation of authority workflow is the HR reporting line for people and the ERP system for cost centre and company code ownership, with the matrix reduced to rules rather than names.
That last part matters. A matrix that lists people has to be edited every time somebody moves. A matrix that lists roles and thresholds only has to be edited when the policy changes, and the people come from a system that is already maintained. In a group with several company codes, this is the difference between a workflow that survives a reorganisation and one that does not — our post on how ERP transforms large enterprises covers why that scale changes the answer.
Write down, before the build: which system owns the reporting line, which owns cost centre ownership, and who may change either.
Decision two: how the thresholds are expressed
Most teams describe thresholds in a meeting and assume they are simple. They are not, and the gaps show up in testing.
Decide the currency question first. If the business runs in several currencies, a threshold has to state which currency it is in and which rate converts a request into it. Then decide whether the threshold applies to the line, the document total, or the annual commitment, because a monthly subscription and a one-off purchase of the same value are not the same risk.
Then decide where the thresholds live. Hard-coding them in the process model means a change request every time finance moves a number. Putting them in the business rules service means finance can change a number without a deployment, which is usually the point of using SAP BTP at all.
Write down, before the build: the currency and conversion rule, what the value is measured against, and who may change a threshold without a release.
Decision three: what happens when the approver is absent
The three cases from earlier need three separate mechanisms, and each needs a rule somebody in the business signs off.
For planned absence, a delegation: the approver names a substitute and a period, and the record shows both. Decide whether the substitute may delegate onward, and whether any approval limit is reduced while delegated.
For silence, an escalation: after a defined wait the request moves to the next level. Decide the wait per request type, not globally, because a payment run and a stationery order do not deserve the same clock.
For a leaver, a reassignment: authority follows the role. Decide who triggers it and how quickly, because this is the case that leaves requests orphaned.
Write down, before the build: the substitution rule, the escalation clock per request type, and the reassignment trigger.
Decision four: what the audit trail stores
An audit trail is cheap to design at the start and expensive to retrofit. The decision is what each approval event records.
At a minimum: the request and its value, the approver, the authority they used, the delegation of authority matrix version in force at that moment, the timestamp, and any comment. If a substitute acted, add who delegated, when, and the period. If an escalation fired, add why the previous step timed out.
Two details get missed. The first is the matrix version. Policies change, and an approval judged against last year's thresholds needs last year's thresholds on the record. The second is the rejection path, because a request that was refused and resubmitted at a lower value is exactly the pattern an auditor looks for.
Decide also how long the record is kept and where. The process engine's own log is not usually the right long-term home for it.
Write down, before the build: the fields captured per event, whether the matrix version is stored, and the retention period and location.
Decision five: where the workflow runs
This is the only decision on the list that is genuinely technical, and it is the one with dates attached.
A delegation of authority workflow on SAP BTP usually needs four things. A process engine to run the approval workflow. A business rules service to hold the thresholds and the matrix logic, so a change is configuration rather than code. Identity, to resolve a role to a person and to carry the substitution. And an integration route into S/4HANA or whichever system holds the document being approved, which is where SAP Integration Suite and the platform's data services come in.
The decision is how much of the logic sits in the process model and how much sits outside it. The rule that holds up: the process model owns the sequence, the rules service owns the numbers, and the ERP system owns the document. Mix those and every policy change becomes a deployment.
Two SAP dates constrain the answer.
SAP Workflow Management is retired; build on SAP Build Process Automation
SAP Workflow Management has reached end of maintenance and its successor is SAP Build Process Automation. SAP documents the transition and the migration path in KBA 3329043. A new delegation of authority workflow should be modelled in SAP Build Process Automation, not in the retired service.
The precise end-of-maintenance dates sit behind an SAP for Me login, so check them against your own contract rather than a blog. What matters for planning is the direction: the old service is not where new work goes, and an existing workflow built on it needs a migration item on the roadmap.
The Neo environment sunsets on 31 December 2028
SAP states in KBA 3365019 that the legacy Neo environment of SAP Business Technology Platform will sunset on 31 December 2028, subject to the terms of customer and partner contracts.
If any part of your SAP BTP estate still runs on Neo, a workflow build is a good moment to confirm that the new work targets the multi-cloud environment instead. Positions were checked on 27 September 2026; verify both before you commit a plan to them.
How the workflow runs, step by step
With the five decisions settled, the build is short. Here is the shape of a working delegation of authority workflow, in the order a request meets it.
The main path
A request arrives. A purchase requisition, a capital request, a contract, a payment release — the document sits in S/4HANA or another system of record, and an event or a scheduled read hands it to the process.
The workflow reads the attributes that decide routing: the value, the currency, the cost centre or company code, the request type, and the requester.
The business rules service turns those attributes into a chain. Not one approver, a chain: the list of levels this request has to clear, derived from the delegation of authority matrix and the thresholds. This is the step worth testing hardest, because everything after it follows from the chain it returns.
Identity resolves each level to a person on the day, applying any active delegation. Level two is not "the finance lead", it is the named person who holds that authority this week.
The first approver gets a task. They approve, reject, or ask a question. The event is written to the audit trail with the matrix version attached.
The request moves to the next level, and repeats until the chain is clear. On the final approval the workflow writes the release back to the system of record, which is the part that makes this automation rather than a signature-collecting app.
The two diversions
A delegation of authority workflow spends most of its life on the main path and earns its keep on the exceptions.
A threshold breach sends the request further up. Somebody edits a requisition upward after it has started, or the currency conversion moves it over a line. The workflow has to re-derive the chain rather than continue with the old one, and it has to say so in the record.
An absence moves the request sideways or up. A delegation hands the task to the named substitute. Silence past the escalation clock hands it to the next level. In both cases the request keeps moving, and in both cases the trail shows why.
Those two diversions are where automation beats the spreadsheet. A matrix in a document cannot notice that a value crossed a threshold, and it cannot notice that nobody has opened the request for four days. If you are weighing this against a bot-driven approach, our post on how RPA is transforming business processes sets out where scripted automation fits and where a process engine is the better tool.
