Dynamics 365 Finance 採購與尋源：工作流程升級後回到同一審批人

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.

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.

2 steps in 1 approval element.

The escalation rows for band A.

Setting Up a Band

1. In the workflow editor, open the approval element and drag a new step above the existing one.
2. 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 <= 1000 with the currency USD.
3. Give the existing step its own range in the same way, for example > 1000 and <= 5000. We would suggest leaving the highest band without an upper limit, so that larger amounts still reach a step.
4. 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.
5. 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 USD for row 1 and >= 50000 USD for row 2. The rows run from the top, so Up and Down will set the order.
6. 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.

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

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

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.