A delegation of authority (DoA) matrix is usually a spreadsheet, and the spreadsheet is usually out of date. Somebody changes role, somebody goes on leave, a threshold moves, and the document that says who may approve what stops matching the company that uses it.
Most guides to delegation of authority workflow automation start with the tooling. This one starts earlier, because the build is not the hard part. Five decisions come before it, and a team that answers them badly ends up with an automated approval workflow that is as wrong as the spreadsheet was, only faster.
SAP BTP is a reasonable place to run this. The platform carries the pieces a delegation of authority workflow needs: a process engine, a business rules service, identity, and a route into S/4HANA. What it does not carry is your approval hierarchy. That part is yours, and it is where these projects succeed or stall.
Two platform dates matter while you plan. SAP Workflow Management has been retired and replaced by SAP Build Process Automation, so a new build should not target the old service. And the legacy Neo environment sunsets at the end of 2028. Both are covered further down with the SAP references.
This guide covers what a delegation of authority workflow has to do, the five decisions to settle before anyone opens SAP Build Process Automation, how the workflow runs step by step, where the same pattern applies outside finance, and four ways these builds go wrong. If you are earlier than that, our guide to ERP implementation best practices covers the ground underneath it.
What a delegation of authority workflow actually has to do
Strip the jargon and a delegation of authority workflow answers three questions about every request that needs a signature. Get all three right and the automation holds. Get one wrong and people go around it.
Who may approve this, at this value
The first job is matching a request to an approver. Not a role in the abstract, a person, on the day the request arrives.
That sounds simple until you write it down. A purchase requisition for a small amount might need one cost centre owner. The same requisition at ten times the value needs the cost centre owner, then a finance lead, then a director. A capital request needs a different chain again. A contract renewal may need legal in the middle of the chain rather than at the end.
So the workflow needs two inputs it cannot guess: the approval hierarchy, and the thresholds that decide how far up the chain a request travels. Both live in your delegation of authority matrix today, usually as a spreadsheet nobody has reconciled to the org chart.
What happens when the approver is not available
This is the question that turns a nice diagram into a real system. People take leave. People change jobs. People sit in a workshop for two days and do not open their approvals inbox.
A delegation of authority workflow needs an answer for each case, and the answers are different. Planned leave is a delegation: a named substitute holds the authority for a stated period. An unresponsive approver is an escalation: after a defined wait, the request moves up. A leaver is a reassignment: the authority follows the role, not the person who used to hold it.
Most failed builds have one mechanism doing all three jobs. That is where requests get stuck, and where somebody starts approving things by email instead.
What has to be provable afterwards
The third job is the audit trail, and it is the one the business case usually forgets and the auditor always asks about.
An approval workflow has to be able to answer, months later, who approved a given request, under which authority, against which version of the delegation of authority matrix, and how long it sat with each person. If a substitute approved it, the record needs to say who delegated, when, and for how long.
That is a design requirement, not a reporting feature. If the workflow does not store it as it runs, no report will reconstruct it later. Our post on how ERP systems improve financial management and reporting covers the reporting side of the same problem.
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.
Where this pattern applies beyond finance
Delegation of authority is usually introduced as a finance control, and the first workflow is usually purchase approval. The pattern is broader than that, and the same five decisions carry across.
HR uses it for offers, salary changes and headcount. The chain depends on grade and cost, and the substitution rules matter more than usual because hiring does not pause for leave.
Procurement uses it for supplier onboarding and contract renewal, where legal often sits in the middle of the chain rather than at the end.
IT uses it for access requests and change approval. The value in the chain is risk rather than currency, so the thresholds are expressed differently while the structure is identical.
Operations uses it for write-offs, credit notes and stock adjustments, which is where the audit trail decision earns its money.
One first-party note, to be completed or removed before publishing. On a proof of concept we built on SAP BTP, approval turnaround time fell by around half. Editor: state the sector, exactly what was measured (for example median hours from submission to final approval on purchase requisitions), and the sample and period the figure covers. If none of that can be confirmed from the project record, delete this paragraph. A number without its basis is worth less than no number.
If the ERP platform underneath all of this is still an open question, our comparison of how to select the right ERP system is the earlier decision.
Four ways a delegation of authority build goes wrong
Each of these is common in DoA workflow automation, and each traces back to one of the five decisions being skipped.
Names in the matrix instead of roles. The build works on day one and decays from day two. Every promotion, transfer and leaver becomes a change request. Model roles and thresholds, and let a maintained system supply the people.
Thresholds in the process model instead of the rules service. Finance moves a number, and a number that should have been a configuration change becomes a deployment. Six months later nobody changes thresholds at all, and the workflow drifts away from the policy it was built to enforce.
One mechanism for all three absence cases. Delegation, escalation and reassignment get collapsed into a single timeout. Requests either sit for days or jump levels they should not have jumped, and both show up in the audit.
An audit trail designed after go-live. The workflow runs, the business is happy, and then somebody asks which matrix version a given approval was judged against. The answer is not in the log, because nothing put it there.
The common thread: all four are decisions taken by whoever happened to be building at the time, rather than by the people who own the policy.
Planning your delegation of authority workflow
Two useful starting points, depending on where you are.
A matrix that exists but is not automated. Send us the matrix and a list of the request types it covers. We will mark which rows can be expressed as rules, which ones hide a judgement call that no rules service can make, and which thresholds contradict each other. Most matrices we read have two or three rows that cannot be automated as written, and finding those before the build is the cheapest hour in the project.
A workflow already built that people work around. Usually one of the four failure patterns above. The diagnosis is quick: look at where requests sit longest and at how many approvals arrive by email instead of through the workflow. Those two numbers point at the decision that was skipped.
Our ERP software development team builds and fixes these on SAP BTP, from the matrix work through to the S/4HANA integration. If the gap is direction rather than hands, IT consulting is the shorter engagement. And if you have the plan but not the SAP capacity, the people who do this work can join your team for the phase that needs them — our guide to explains how that is scoped.No obligation, and no pitch deck.
Frequently asked questions
What is a delegation of authority workflow?
It is the process that decides who may approve a given request, routes it to those people in order, and records what happened. The rules come from a delegation of authority matrix, which sets out approval limits by role, value and request type. Automating it means the routing, the substitution and the audit trail run in a system rather than in a spreadsheet and an inbox.
How do you automate delegation of authority using SAP BTP?
Four platform pieces do the work. SAP Build Process Automation runs the approval workflow and issues the tasks. The business rules service turns a request's value, currency, cost centre and type into the chain of approvers it has to clear. Identity resolves each level to a person and applies any active delegation. And an integration route, typically through SAP Integration Suite, writes the release back into S/4HANA or the system holding the document. The five decisions in this guide come before any of that.
Which SAP BTP service should a new approval workflow use?
SAP Build Process Automation. SAP Workflow Management has reached end of maintenance and SAP documents the successor and the migration path in KBA 3329043. Check your own contract for the exact dates, because those sit behind an SAP for Me login.
Where should the delegation of authority matrix live?
In the business rules service, expressed as roles and thresholds rather than names. A matrix that lists people needs editing every time somebody moves job. A matrix that lists roles and limits only changes when the policy changes, and the people are supplied by HR and the ERP system, which are already maintained. Keep the thresholds out of the process model so finance can change a number without a deployment.
What should the audit trail record for each approval?
The request and its value, the approver, the authority they acted under, the version of the delegation of authority matrix in force at that moment, the timestamp and any comment. Add the delegator, date and period when a substitute approved, and the reason when an escalation fired. Record rejections and resubmissions too. The matrix version is the field most often missed and the one most often asked for later.
What happens when an approver is on leave?
Three different cases need three mechanisms. Planned leave is a delegation to a named substitute for a stated period, with the record showing both. An approver who simply does not respond triggers an escalation after a wait set per request type. A leaver triggers a reassignment, because the authority belongs to the role rather than the person. Collapsing all three into one timeout is the most common reason an automated approval workflow gets bypassed.
