Approvals

This page explains how purchase requests are approved, and how to set up the rules, paths and roles that decide who approves what.

In short: rules decide which approval path a requisition line follows, the path lists the levels of approval in order, and each level names an approval role that is filled by the right person for that particular line.

How it works

Requisition line
   │  1. MATCH     The first Approval Rule whose condition fits the line
   │               decides which Approval Path it follows.
   ▼
Approval set
   │  2. GROUP     Lines on the same rule are grouped (for example by branch
   │               or by project) and their amounts are totalled.
   ▼
Levels
   │  3. ASK       Levels are opened one at a time. At each level, the role
   │               is filled by the people who hold it for these lines.
   ▼
Approved
      4. DONE      When the rule's conditions are met, the set is approved
                   and its lines are released.

Approvals use Business Central's standard approval entries, workflows, notifications and the Requests to Approve page. What the approval rules add is the decision about who is asked, in what order, and when enough people have approved.

Key terms

Term	Meaning
Approval Rule Set	A named group of approval rules. You can have several; they're checked in priority order.
Approval Rule	A condition that selects requisition lines, the approval path those lines follow, and the terms of approval: how many different people must approve, whether the requester may approve, and how line amounts are totalled.
Approval Path	An ordered chain of approval levels, for example Branch Manager → Regional Manager → CFO. One path can be used by several rules.
Level	One step of a path: the role that approves at that step, and how much that step may authorise.
Approval Role	A job, such as Branch Manager or CFO. A role has no people of its own; Approval Role Users decides who holds it for a given line.
DFA	Delegated Financial Authority: the amount, in local currency, that a level may authorise.
Approval Set	What's actually approved: one or more lines of a request that share a rule, with one total amount. A request can have several approval sets, and they're approved independently.

Before you start

• Approvers must be Business Central users with a record on the Approval User Setup page.
• Requesters who are also Business Central users are linked to their user by the BC User ID on the requester card. It's filled in automatically when the requester's e-mail matches a user's authentication or contact e-mail. Check it for anyone whose portal e-mail differs from their Business Central one, and set it yourself if needed. This link is how the Self-Approval rule recognises the requester.
• Decide which spend needs which approval chain. It's easiest to sketch the paths first (who approves, in what order, up to what amount), then the rules that send lines to them.
• Test in a sandbox before you enable approval rules in production.

Important

As soon as any approval rule set is enabled, every purchase request sent for approval uses approval rules. The older Approval Routing setup is then no longer used. If you disable every rule set, requests go back to using Approval Routing.

Set up approvals

The approval setup pages are available from Purchase Requisition Setup under Approvals, or by searching for the page name.

1. Set up the approval workflow

Approval rules run inside a Business Central approval workflow.

1. Search for Workflows and choose New Workflow from Template.
2. Select Purchase Request Approval Workflow (category Purchase Request).
3. Check the step Create an approval request for the record using approver type…. Its Approver Type must be Approval Routing. The template sets this for you. If you build the workflow yourself, set it here.
4. Turn on Enabled.

warning

If the approver type is anything other than Approval Routing, Business Central's standard approvals are used instead. No approval sets are created, and your approval rules are ignored.

2. Create approval roles

Open Approval Roles and add one row per role, with a Code and a Name. For example:

Code	Name
BRANCHMGR	Branch Manager
REGMGR	Regional Manager
CFO	Chief Financial Officer
CAPEXREV	CapEx Reviewer

3. Assign users to roles

Open Approval Role Users (or choose Users on the Approval Roles page). Each row says that a user holds a role, and for which lines.

Field	What it does
User Code	The approver. They must have an Approval User Setup record.
Role	The approval role they hold.
Role Type	What decides whether they hold the role for a given line. See the table below.
Role Filter	Which records of that type they cover. Use the … button to pick values. Leave it blank to cover every record of that type.

Role Type	The user holds the role for a line when…	Example Role Filter
(blank)	Always. Use this for roles like CFO.	(none)
Dimension	The line's dimensions match the filter.	Dimension Code: BRANCH, Dimension Value Code: AKL
Vendor	The line's vendor matches the filter.	No.: V1000|V2000
Project Manager	The user is the Project Manager on the line's project. Nothing else needs to be maintained.	(none)
Project	The line's project matches the filter.	No.: PR-0042
Project Task	The line's project task matches the filter.	Project Task No.: 1000..1999
Item Category	The line's item is in a matching item category.	Code: IT
Line Filter	The requisition line itself matches the filter.	Estimated Amount (LCY): >5000

Filters use standard Business Central filter syntax, so one row can cover several values. For example, AKL|WLG makes one person the manager of two branches. Dimension filters always use the line's dimensions, not the header's.

tip

Adding a new branch or project usually means adding one row here. You don't need a new rule or path.

4. Create approval paths

Open Approval Paths and create a path for each approval chain. On the Levels tab, add the steps in order:

Field	What it does
Level	The order the levels are opened in, lowest first.
Approval Role	The role that approves at this level.
Description	A note for administrators.
DFA Level Value	The most this level may authorise, in local currency. 0 means the level carries no financial authority. Use it for a reviewer who must sign off but can't approve spend.
Mandatory	This level can't be skipped: someone at it must approve, even when a later level would already have enough authority. If nobody can be found to approve at a mandatory level, the approval set is blocked.

Example paths:

Path	Level	Approval Role	DFA Level Value	Mandatory
STANDARD	1	Branch Manager	10,000
STANDARD	2	Regional Manager	50,000
STANDARD	3	CFO	1,000,000
CAPEX	1	CapEx Reviewer	0	Yes
CAPEX	2	Regional Manager	50,000
CAPEX	3	CFO	1,000,000

Highest DFA Level Value shows the most a path can authorise. An approval set worth more than this can never be approved on that path and will be blocked. Check it against the spend the path is meant to cover.

info

Financial authority comes from the level, not from the person. The same person can approve up to 10,000 as Branch Manager on one path and up to 50,000 at a higher level on another. The DFA Level on Approval User Setup isn't used to decide authority; it's only checked when you choose a substitute (see Substitutes).

5. Create approval rule sets and rules

Open Approval Rule Sets and create a rule set.

Field	What it does
Code, Description	Identify the rule set.
Priority	The order enabled rule sets are checked in, lowest first.
Enabled	Only enabled rule sets are used.

On the Rules tab, add the rules. They're numbered in steps of 10, so you can slot one in later.

Field	What it does
Step	The order rules are checked in within the set.
Description	What the rule is for.
Condition	Which lines the rule applies to, for example Shortcut Dimension 4 Code: <>''. Use the … button to build it from the line fields. Blank matches every line.
Approval Path	The path matching lines follow. A rule without an approval path never matches anything.
Self-Approval	Whether the requester may approve their own request. When this is cleared, the requester is left out of every level and someone else must approve. If nobody else can, the approval is blocked rather than released. The requester is recognised through their requester's BC User ID.
No. of Approvers	How many different people must approve. Set 2 for a four-eyes check. One approval settles a level, so each approver comes from a different level: a rule that needs 2 approvers needs a path with at least 2 levels that can find someone. See When a set is approved.
Aggregation Rule	How matching lines are grouped before their amounts are totalled. See Grouping lines.
Aggregation Dimension	For the dimension-based aggregation rules, which dimension(s) to group by. Use the … button to tick them.

Example rule set:

Step	Description	Condition	Approval Path	No. of Approvers	Aggregation Rule	Aggregation Dimension
10	Capital spend	Shortcut Dimension 4 Code: <>''	CAPEX	2	By Dimension Value	CAPEX
20	Everything else	(blank)	STANDARD	1	By Dimension Value	BRANCH

Add a catch-all rule

Every line must match a rule. Add a last rule with a blank condition so nothing falls through. A line that matches no rule can't be sent for approval: it's rejected, and the reason is shown in Desired Status Error, while the request's other lines go ahead. If no line matches any rule, nothing on the request can be sent.

Changing rules. You can't change the rules of an enabled rule set. That protects requests already part-way through approval. To make a change without a gap, create a new rule set with a lower Priority number, enable it, and then disable the old one. If you disable every rule set, even briefly, requests sent in the meantime use the older Approval Routing setup.

6. Set up substitutes for absences

When an approver is away, their Substitute approves for them.

• On Approval User Setup, set Substitute, and optionally Substitute From and Substitute To. Blank dates mean open-ended. The substitute's DFA Level must be at least the approver's.
• If Allow Approver Self-Service is turned on in Purchase Requisition Setup, approvers can maintain their own substitute from My Settings.
• While the substitution period covers today, the substitute is asked instead of the absent approver. They're shown as Acting for that person.
• The substitute must be able to cover the role. They must hold the same role themselves (for any line, so one branch manager can cover another), or hold a role that's allowed to cover it, or be an Approval Administrator. To allow one role to cover another, choose Cover Authorization on the Approval Roles page. A substitute who can't cover the role is shown on the plan as Excluded, and the level falls back to the role's other holders, or to the next level.
• Delegate All Open Entries on Approval User Setup hands everything already waiting for a user to their substitute. The same cover rule applies.

7. Check related settings

On Purchase Requisition Setup:

Setting	What it does with approval rules
Auto Release If No Workflow/Approver	Only decides what happens when no approval workflow applies to a request at all. A line that can't be sent for approval, for example because of a setup problem, is always rejected, never released, whatever this setting says.
Force Approval Enabled	Lets Approval Administrators release a request without waiting for the normal approvals. See Force Approval. Keep it off unless you need an emergency override.
Allow Approver Self-Service	Lets approvers maintain their own substitute.

How a request is approved

Matching lines to rules

When a request is sent for approval, each line is checked against the rules of the enabled rule sets: rule sets by Priority, then rules by Step. The first rule that matches wins, and the line follows only that rule. Put specific rules first and the catch-all last.

Grouping lines into approval sets

Lines that match the same rule are grouped into approval sets according to the rule's Aggregation Rule. Their amounts are totalled, and the total is what financial authority is tested against. This stops a large purchase being split across several small lines to stay under a limit.

Aggregation Rule	Lines on the same rule are grouped…
By Request	All together, into one set for the whole request.
By Vendor	By vendor.
By Dimension Value	By the value of the chosen dimension(s), for example one set per branch.
By Dimension Code	By whether the chosen dimension(s) are filled in on the line, not by their value.
By Project	By project.
By Project Task	By project and project task.

Amounts are always compared in local currency (LCY). A set whose lines use different currencies is flagged Mixed Currency, and only its LCY total is shown.

Levels and who is asked

When the request is sent, the whole plan is worked out: every level of each set's path, and who is expected to approve at each. You can see it straight away with Approval Plan.

Then, for each set:

1. The first level opens. Everyone who holds that level's role for the set's lines is asked at the same time. Each person gets an approval request and a notification.
2. The first approval settles the level. A role means "any one of the people who hold it for these lines". As soon as one of them approves, the others at that level are stood down: their approval requests are cancelled, and the plan shows them as Cancelled. If the set isn't complete yet, the next level opens.
3. People are re-checked when a level opens. If someone in the plan is no longer available (their user is disabled, they're now away with a substitute, or they no longer hold the role), that level's approvers are worked out again.
4. Levels nobody can approve are skipped. A level where no eligible approver can be found is marked Skipped, and the next level opens.

Separate approval sets on the same request run in parallel. Within a set, levels open one at a time.

When a set is approved

After each approval, the set is approved when all of these are true:

1. Every mandatory level has been completed.
2. Someone has approved at a level whose DFA Level Value covers the set's amount.
3. At least No. of Approvers different people have approved. One person counts once, however many levels they approve at. Approvals at reviewer levels (DFA Level Value 0) don't count towards this number.
4. The requester hasn't approved it, if the rule doesn't allow Self-Approval.

When the set is approved:

• Anyone still waiting on it is stood down: their approval requests are cancelled and they're shown as Cancelled on the plan.
• Levels that weren't needed are marked Skipped ("Not required…").
• Each line is Released once every set it belongs to is approved.

If the set runs out of levels before all four conditions are met, it's Blocked, not approved. See Blocked approval sets.

Worked example

The request below uses the example roles, paths and rules above:

Line	Branch	CapEx code	Amount (LCY)	Rule	Approval set
10000	AKL		12,000	Step 20	STANDARD, BRANCH=AKL
20000	AKL		8,000	Step 20	STANDARD, BRANCH=AKL
30000		CX-26-01	30,000	Step 10	CAPEX, CAPEX=CX-26-01

Set 1: STANDARD for AKL, 20,000, 1 approver required

Level	Who	Result
1 Branch Manager (10,000)	R. Chen approves	10,000 doesn't cover 20,000, so level 2 opens.
2 Regional Manager (50,000)	M. Patel approves	Authority covers the amount, and 2 people have approved (1 needed). The set is approved. Level 3 is skipped.

Lines 10000 and 20000 are released.

Set 2: CAPEX, 30,000, 2 approvers required

Level	Who	Result
1 CapEx Reviewer (0, mandatory)	L. Novak signs off	The mandatory level is done, but a reviewer has no authority and doesn't count as an approver. Level 2 opens.
2 Regional Manager (50,000)	M. Patel approves	Authority now covers 30,000, but only 1 approver counts (2 needed). Level 3 opens.
3 CFO (1,000,000)	S. Okafor approves	2 approvers. The set is approved.

Line 30000 is released. M. Patel approved in both sets. That's fine, because each set is counted on its own.

Rejection

A rejection by anyone rejects that whole approval set straight away. The other people waiting at that level are stood down, and the set's lines are marked Rejected. Other approval sets on the same request carry on.

Cancelling and resubmitting

• Cancel Approval Request on the purchase request cancels every open approval request, removes the approval plan and puts the lines back to Open, so they can be changed and sent again.
• To resubmit a rejected request, choose Reopen and then Send Approval Request. Rejected, blocked, cancelled or force-approved approval sets are removed, and a new plan is worked out from scratch using the current rules, paths and role users.

Changes to rules, paths and levels only affect requests sent after the change. A request already in approval keeps the plan it was given when it was sent.

For approvers

When a level opens for you, you receive a Business Central approval notification.

• Open Requests to Approve to see everything waiting for you, or open the purchase request itself. The request shows Approve, Reject and Delegate when something is waiting for you.
• Your approval request is raised against the purchase request, and its amount is the total of the approval set you're approving. The Requester column shows who the request is for.
• On the request's lines, the Approval column shows Awaiting Your Approval on the lines your decision covers, and Not Yours to Approve on the others. A request can have lines on different approval paths.
• Delegate passes your approval request to your substitute. The substitute must be able to cover the role you're approving for (see Substitutes). They also can't be the requester, if the rule doesn't allow self-approval. Otherwise the delegation is refused. The Approval Plan keeps your row, marked Delegated, and adds a row for the person who now has it.

Following an approval

On a purchase request line, under Approval:

• Approval Sets shows the sets the line belongs to: status, path, current level, amount, and how many different people have approved against how many are needed.
• Approval Plan shows every level of every set the line belongs to, including levels not reached yet: who is expected to approve, who has, when, and why anyone was left out. Decided By shows who actually recorded each approval or rejection. It only differs from the approver when an Approval Administrator decided on their behalf.

The Approval Sets page can also be opened on its own, for example to find every blocked set. From it, choose Levels, Approvers or Requisition Lines.

The approval plan is also synced to the portal, so requesters can see who has approved and who is next.

Statuses

Approval set status	Meaning
Planned	Worked out but not started.
Active	In approval. Current Level shows the level that's open.
Approved	All conditions met.
Rejected	Someone rejected it.
Blocked	It can't be approved with the current setup. See Blocked Reason.
Cancelled	The approval request was cancelled.
Force Approved	Released by an Approval Administrator with Force Approval, without its rule being met. Blocked Reason still shows what was missing.

Level status	Meaning
Planned	Not reached yet.
Active	Open for approval.
Approved	Completed.
Rejected	Rejected at this level.
Skipped	Not needed, or nobody eligible could be found (see Skip Reason).

Approver decision	Meaning
Pending	Waiting, or not reached yet.
Approved / Rejected	The person's decision.
Delegated	The person handed their approval request on. A new row at the same level shows who has it now.
Cancelled	No longer needed: someone else at the level approved, the set was approved or rejected, or the request was cancelled.

Blocked approval sets

A set is Blocked when it has run out of levels and still can't be approved. Blocked sets are never released automatically. The Blocked Reason says what's missing:

Blocked Reason	What to check
A mandatory approval level has not been completed.	Nobody could be found to approve at the mandatory level, so it was skipped. Check the role's users on Approval Role Users.
Nobody has approved at a level with delegated financial authority covering…	The set's amount is more than the path's Highest DFA Level Value, or the levels that could cover it found nobody.
This rule requires 2 different approvers but only 1 have approved.	Each level supplies one approver, so the path doesn't have enough levels that can find someone. Add levels or role users, or review No. of Approvers.
The requester approved their own request…	The requester was among the approvers under a rule that doesn't allow self-approval.

To fix a blocked request, correct the setup, choose Cancel Approval Request on the purchase request, and then send it again. In an emergency, an Approval Administrator can use Force Approval instead.

Force Approval

Force Approval on the purchase request releases it without waiting for the normal approvals. It's only available to users marked Approval Administrator on Approval User Setup, and only while Force Approval Enabled is turned on in Purchase Requisition Setup.

On a request that's pending approval:

1. Every outstanding approval is approved in the administrator's name, level by level, until each approval set is complete or has nothing left to ask.
2. Any approval set that still can't be completed, for example a blocked one, is marked Force Approved. Its remaining levels are skipped and anyone still waiting is stood down.
3. All lines are released.

Force Approved is kept apart from Approved, so the record never claims the approval rule was met. The set's Blocked Reason still shows what was missing.

Force Approval is recorded on the approval sets:

• Force Approved By and Force Approved At are filled in on every set that was still in approval. This includes sets that then finished as Approved because their approvals were completed in the administrator's name.
• On the Approval Plan, Decided By shows the administrator against each approval made on someone's behalf.

Troubleshooting

When a request can't be sent for approval, the reason is shown in red in the Desired Status Error field on the purchase request. It's cleared the next time the request is sent.

Problem	Cause and fix
No approval sets are created when a request is sent	The workflow's Approver Type isn't Approval Routing, so standard approvals ran instead. Or no approval rule set is Enabled, so the older Approval Routing setup was used.
No approval rule matches any line of purchase request…	No rule matched. Check each rule has an Approval Path, and add a catch-all rule with a blank condition.
A line is Rejected straight away with Line … matches no approval rule…	That line matched no rule, so there's nobody to approve it. The request's other lines were sent as normal. Add a catch-all rule, then reopen the line and send it again.
This approval cannot be delegated to…	The substitute doesn't hold the role or a role allowed to cover it, and isn't an Approval Administrator. Or they're the requester. Choose another substitute, or allow their role on Cover Authorization.
…matches an approval rule, but no purchase request approval workflow is enabled…	Enable the Purchase Request Approval Workflow. See step 1.
A level is Skipped with No eligible approver could be resolved…	Nobody holds the level's role for these lines. Check Approval Role Users: the role type and filter, and that the user has an Approval User Setup record.
The wrong person was asked	Open Approval Plan. Resolved Via shows whether they were asked through their role, as a substitute (Acting for), or after a delegation (Delegated by). Then check the rule the line matched: rule set Priority and rule Step decide which rule wins.
A substitute is shown as Excluded	They don't hold the role they were standing in for or a role allowed to cover it, and aren't an Approval Administrator. See Substitutes.