Applies to: Dynamics 365 Finance, purchase requisition approval workflows. Tested on version 10.0.46 (platform update 70) in the USMF demo company, October 2026.
CodeCore Dynamics LLC. 20 October 2026.
In our test, an overdue purchase requisition approval was escalated from the approver back to the same approver. The workflow history records it as Escalated from: ESC Manager to ESC Manager.
A Dynamics User Group thread, Workflow escalation to next level in hierarchy, describes the same behaviour. We set it up again in the USMF demo company to see where the escalation looks for its next approver, and which settings move an overdue approval to the level above.
An escalation given the same settings as the approval step will find the same person again, because it runs its own search from a person on the document and has no option for the current approver. To move an overdue approval to the level above whoever holds it, we gave each amount band its own approval step with its own escalation rows. In our test, a 500 requisition then moved from the Lead to the Manager and on to the Director, and a 3,000 requisition from the Manager to the Director.
The escalation returned the task to the person who already had it.
The Setup
In the thread, the approval step used the organisational hierarchy with approval limits, and each requisition reached the first manager whose limit covered the amount. Overdue approvals were meant to go to the level above. The escalation was given the same hierarchy as the approval step, and the task came back to the same person.
We created 4 workers in USMF, each reporting to the next, with signing limits for purchase requisitions: ESC Requester (0.01), ESC Lead (1,000), ESC Manager (5,000) and ESC Director (50,000). The names and limits were created for the test. A requisition for 3,000 should therefore reach the Manager, and an escalation 1 level up should reach the Director.
The approval step uses the Managerial hierarchy, starts from the Requester, stops at the first person whose approval limit for purchase requisitions is at least the requisition's approval amount, and assigns the last person it retrieves.
The approval step, starting from the requester and stopping at the first sufficient limit.
We then gave the escalation the same settings, as in the thread.
The escalation with the same hierarchy, starting point and stop condition.
Cause
The escalation does not continue from the person who holds the task. It runs its own hierarchy search, with its own starting point and stop condition. Microsoft Learn describes the escalation's hierarchy option in the same way as the approval step's: "To specify the starting point, select a person in the Start from list." (Configure approval steps in a workflow). With the same settings, the search will return the same person.
In 10.0.46 the escalation's Start from list has the same 5 options as the approval step: Preparer, Requester, Submitted by, Workflow originator and Workflow owner. Each of them is a person on the document. We did not find an option for the person who currently holds the work item.
The starting points on offer for an escalation.
An escalation of type Workflow user offers Workflow originator, Work item owner and Workflow owner. Work item owner refers to the current holder, so it would escalate to the same person, and the list has no option for that person's manager. Our tests used configuration only. We did not look at code changes, so we cannot say whether a developer could add a starting point for the current approver's manager.
The Workflow user options for an escalation.
To see whether the result depends on who holds the task, we changed the approval step so that 2 more requisitions went first to the Lead, and left the escalation as it was.
| Requisition | First approver | Escalation | Escalated to |
|---|---|---|---|
| ESC-E1 | ESC Manager | starts from the requester, stops at limit >= amount | ESC Manager |
| ESC-E2 | ESC Lead | the same as ESC-E1 | ESC Manager |
| ESC-E3 | ESC Lead | the same as ESC-E1 | ESC Manager |
The escalation reached the same person each time, whoever held the task before it. Where the approval starts lower, the escalation can look as if it moved 1 level up, which may be why the same setup appears to work in some cases.
Escalating to a Fixed Level
We tested 2 changes with a 3,000 requisition. Both moved the overdue task from ESC Manager to ESC Director.
Higher Stop Condition
The escalation keeps the requester as its starting point and stops at the next limit up, here Employee.Approval limit.Purchase requisition >= 50000 USD. The search then passes the Manager and stops at the Director. Our test used =, which only matches because the Director's limit is exactly 50,000, whereas >= will also work where the next limit is higher. When the condition compares against a typed amount, the editor will ask for a currency (A currency code must be specified).
Escalated from ESC Manager to ESC Director with a higher stop condition.
Named User
The escalation's assignment type is set to User, with the person selected.
Escalated from ESC Manager to ESC Director as a named user.
The target is fixed in both cases. With the 50,000 rule, we would expect a 500 requisition approved by the Lead to go to the Director as well, although we did not test this, and a named user will receive every overdue item. Either may suit a business with 1 approval level above the first approver. Where the level above depends on the amount, the setup below may suit better.
Escalation by Amount Band
Where the next level depends on the amount, each amount band can have its own approval step. An approval element can hold several steps, and Learn notes that "The approval step can always be required, or it can be required only if specific conditions are met." (Configure approval steps in a workflow). Each step below has a condition on the requisition amount, the same approval assignment as before, and its own escalation rows.
| Step | Runs when | First approver | Escalation 1 | Escalation 2 | Then |
|---|---|---|---|---|---|
| ESC band A | amount <= 1,000 | ESC Lead | stops at limit >= 5,000 (ESC Manager) | stops at limit >= 50,000 (ESC Director) | Reject |
| ESC approval | amount > 1,000 and <= 5,000 | ESC Manager | stops at limit >= 50,000 (ESC Director) | none | Reject |
2 steps in 1 approval element.
The escalation rows for band A.
Setting Up a Band
- In the workflow editor, open the approval element and drag a new step above the existing one.
- On the new step's Condition, select Run this step only when the following condition is met and add the amount range, for example
Purchase requisitions.Approval amount <= 1000with the currency USD. - Give the existing step its own range in the same way, for example
> 1000and<= 5000. We would suggest leaving the highest band without an upper limit, so that larger amounts still reach a step. - On Assignment, use the same hierarchy, Start from and stop condition as the existing step. The Time limit tab is worth checking too, as a new step defaults to Non-calendar.
- On Escalation, select Use escalation path and add 1 Hierarchy row for each level above the band. Each row starts from the Requester and stops at the next approval limit, for example
Employee.Approval limit.Purchase requisition >= 5000 USDfor row 1 and>= 50000 USDfor row 2. The rows run from the top, so Up and Down will set the order. - Select the Action row and choose the end action.
The workflow history shows which step ran. For a 3,000 requisition it records Pre-condition: ESC band A evaluated to False and then Pre-condition: ESC approval evaluated to True, and assigns the Manager. For a 500 requisition, band A evaluates to true and the Lead receives it.
A 500 requisition, assigned to the Lead under band A.
With 1-hour time limits for the test, both requisitions were escalated at the same batch run. The 3,000 requisition was escalated from ESC Manager to ESC Director, and the 500 requisition from ESC Lead to ESC Manager.
The 500 requisition, escalated from the Lead to the Manager.
When the Manager also left the 500 requisition, it was escalated a second time, from ESC Manager to ESC Director, recorded as Escalation level: 2.
The 500 requisition, escalated a second time to the Director.
The 3,000 requisition had no further escalation row. When the Director did not act either, the end action ran. The history records Final escalation action: Reject and Rejected by: ESC Director. The rejection is recorded in the Director's name, although the Director did not act, and a new work item was assigned to ESC Requester.
The end action, after the last escalation.
| Amount | Step | First approver | Escalation 1 | Escalation 2 | At the end of the test |
|---|---|---|---|---|---|
| 500 | ESC band A | ESC Lead | ESC Manager | ESC Director | With ESC Director |
| 3,000 | ESC approval | ESC Manager | ESC Director | none | Rejected and returned to ESC Requester |
Of the setups we tested, this was the only one that moved each overdue approval to the level above whoever held it, for both amounts.
The bands and escalation rows repeat the signing-limit levels, so a change to the limits will also need a change to the workflow. The escalation reaches the next approval limit above the band. In our hierarchy that is the next manager, because each level has a higher limit. Where 2 people in a row share a limit, we would expect the escalation to pass the second, although we did not test this.
If an amount falls outside every band, the requisition may not be approved by anyone. While we were building this, a saved version lost band A, and a 500 requisition matched no step. The approval element completed, the workflow finished, and the requisition's status changed to Approved. Our ESC approval step also stopped at 5,000, so we would expect a requisition above 5,000 to go through in the same way, although we did not submit one.
No step matched, and the workflow completed without an approver.
The first 500 requisition, ESC-B1, approved without an approver.
Issues Found While Testing
| What we saw | Cause | What we changed |
|---|---|---|
| The approval step started from the preparer | Preparer is the default Start from | Start from set to Requester |
| New requisitions still went to the demo workflow after Set as default | Demo workflow 000062 has an activation condition, which was used before the default | Condition switched off |
| Insufficient security permissions for user escmgr | The approvers had only the Employee role | Purchasing manager added, then Resume |
| A 1-hour limit set on a Friday came due on Monday at 9:00 | A new step defaults to Non-calendar, Monday to Friday, 8 hours from 8:00 AM | All 7 days, 24 hours from 12:00 AM |
| Nothing escalated for several days | Workflow due date processing had ended after 1 run | Recurrence set with no end date |
Workflow due date processing with the status Ended on our environment.
The job saves history for errors only, so a successful run will not appear in its history. The start time of its batch task shows when it last ran.
In the editor, the Escalate to column shows internal names. Preparer appears as Originator, which differs from the Workflow originator option (WorkflowOriginator). Add escalation inserts the new row above the existing ones.
Checks
| Check | Where | You should see | If not |
|---|---|---|---|
| The escalation's starting point and stop condition | Approval step > Escalation > the escalation row | A stop condition that reaches a higher approval limit than the approval step's | The escalation will return the same approver |
| The due date batch job | System administration > Inquiries > Batch jobs > Workflow due date processing | Waiting, with a recurrence and no end date | No escalation will run |
| Roles of every escalation target | System administration > Users > Users | A role that can open purchase requisitions | The workflow will stop with a security error |
| Bands, if used | Each step's Condition | Every amount covered by 1 step, with no upper limit on the highest band | Some requisitions may complete without an approver |
Sources
- Configure approval steps in a workflow
- Workflow escalation to next level in hierarchy, Dynamics User Group
On Method
All tests used the USMF demo company on Dynamics 365 Finance 10.0.46 (platform update 70) between 14 and 19 October 2026. The workers, limits and amounts were created for the test, and the time limits were shortened to 1 hour. The forum thread is paraphrased and linked.
This article was assisted by Claude (Anthropic).
About Author
Dean Fachrie is a Dynamics Functional Analyst at CodeCore Dynamics LLC, working on Microsoft Dynamics 365 F&O architecture and enterprise system design.
Setting up approval workflows in Dynamics 365 Finance, or finding overdue approvals that stay with the same approver?
We help finance and procurement teams design purchase requisition workflows so that approval limits, escalations and the batch jobs behind them work together.
Contact us or connect on LinkedIn for architecture reviews.
Top comments (0)