---
title: Setting Up Order Approval | Shopware Community Hub
description: >-
Configure Order Approval rules that define which roles approve orders and
which roles need approval, optionally with spending thresholds, for controlled
B2B…
canonical_url: >-
https://hub.shopware.comhttps://hub.shopware.com/learn/unit/setting-up-order-approval
---
# Setting Up Order Approval
- Understand why B2B ordering may need approval before an order becomes binding.
- Distinguish between roles that can approve orders and roles whose orders need approval.
- Configure an approval rule with an optional spending threshold in the storefront company account.
- Verify the approval flow in the storefront from the buyer and approver perspective.
# Setting Up Order Approval
In a business, not everyone who fills a cart is allowed to commit the company's money. A trainee may prepare an order, but a manager must sign it off. Above a certain amount, even an experienced buyer may need approval. This kind of control is common in procurement, but it is not part of a standard consumer checkout.
Order Approval adds this control to the business-to-business (B2B) checkout. It lets you define rules so that selected orders are submitted for approval before they become binding. This learning unit shows you how approval rules build on B2B roles, how Order Approval is prepared in the administration, and how you configure and verify the approval flow in the storefront company account.
Order Approval is available from Shopware 6.5.8.0. If approval options are missing, confirm the Shopware version and that Order Approval is activated for the customer.
## Continue in Your Learning Environment
Use the learning environment from the previous course to follow the Order Approval flow. If you have not opened it yet, open it here before you continue.
For this learning unit, use a B2B-enabled customer account where Employee Management, Roles, and Order Approval are active. You need accepted employee invitations, a **Buyer** role from the previous course, and products that can be added to the cart. During this learning unit, you will create the second role that can approve orders.
## Why Approval Exists in B2B
Standard checkout assumes that the person buying is also allowed to buy. In B2B, that assumption often breaks down. Spending authority is distributed, and companies may need oversight before money is committed.
> Order Approval inserts a sign-off step between placing an order and the order becoming binding, based on who the buyer is and how large the order is.
This protects the customer's purchasing process. It prevents unauthorized or oversized purchases, gives approvers visibility, and maps internal procurement rules into the shop. Your task as a shop administrator is to enable the function, understand the rule model, and verify that the customer's approval policy works in the storefront.
Order Approval does not replace employee permissions. Permissions decide whether an employee may place an order at all. Approval decides whether an order that was placed by an allowed employee needs sign-off before it becomes binding.
## The Two Sides of an Approval Rule
Approval rules model a common company process: One employee can prepare or place an order, but another person with the right responsibility must approve it before it becomes binding.
With Shopware B2B Components, you can define this kind of approval process for a B2B company account. The approval rule connects the role whose orders need approval with the role that can approve those orders.
An approval rule connects two sides:
- **Roles that can approve orders**: Senior responsibilities such as managing director or purchasing manager.
- **Roles whose orders need approval**: Responsibilities such as trainee, assistant buyer, or buyer.
The rule says: "Orders placed by employees with this role must be approved by employees with that role." Because employees inherit their permissions and responsibilities through roles, the approval behavior applies to everyone assigned to the role.
You can refine this with a **spending threshold**. Instead of requiring approval for every order, approval is required only when the order matches a condition, for example when the value is above EUR 5,000. Small routine orders can continue normally, while larger orders stop for sign-off.
## Create Approval Rules in the Storefront
For this topic, the customer needs the **Order Approval** feature from B2B Components. In your learning environment, the feature should already be active for the B2B customer.
The rule setup now happens in the storefront company account.
Log in as your B2B customer, open the account overview, go to **Approval rules**, and select **Create rule**.
The **New approval rule** page shows the role model you learned above. The rule needs a name, a role that gives order approval, and a role that needs order approval.
At this point, the form reveals a setup gap. You already have a **Buyer** role from the previous course. This role can be used for **Needs order approval**, because buyers may place orders that require sign-off.
The rule also needs a role for **Gives order approval**. In this setup, no fitting role exists yet.
## Exercise: Create an Approving Role
Before you can finish the approval rule, create the missing approving role. This reuses the role workflow from the previous course in a new ordering context.
1. Open the **Roles** area in the storefront company account.
2. Create a role named **Management**.
3. Enable the permissions to view, create, and edit approval rules.
4. Enable **View all pending orders** and **Approve and decline pending orders**.
5. Do not activate **Default role for new employees**.
6. Assign the role to at least one active employee.
After this exercise, you have both sides of the approval rule:
- **Management** gives order approval.
- **Buyer** needs order approval.
## Complete the Approval Rule
Now create a rule for a concrete purchasing situation: Buyer orders that use **Cash on delivery** need approval from the Management role.
This use case is about a payment choice with extra handling and accounting risk, so the customer wants the Management role to check it before the order becomes binding.
Configure the approval rule like this:
1. Enter a clear name, for example **Cash on delivery approval**.
2. Set the priority to **1**.
3. Select **Management** for **Gives order approval**.
4. Select **Buyer** for **Needs order approval**.
5. Set **Applies to** to **Custom condition**.
6. Choose the condition **Applied payment method**.
7. Select the operator **Is equal to**.
8. Select **Cash on delivery** as the payment method.
9. Save the approval rule.
This is the configuration side of the feature. The employee is not approving a specific order here. They are defining the rule that Shopware will later apply during checkout.
Do not create approval rules only because the feature exists. First ask which employees may order freely, which orders need sign-off, who may approve them, and whether the order value changes the decision.
As approval requirements become more complex, the customer can create multiple approval rules to reflect different responsibilities or purchasing scenarios. This keeps approval logic flexible without changing the underlying role structure.
## Verify the Flow in the Storefront
Order Approval changes the buying flow itself. You only know whether the rule works when you test both sides in the storefront.
- For a buyer whose role needs approval, checkout ends by submitting the order for approval instead of completing it immediately. The buyer sees that the order is waiting for approval.
- For an approver, the storefront shows pending orders that need a decision. Approving makes the order binding. Rejecting stops it.
The approver works in the storefront, where the pending order can be accepted or rejected. The exact order details in your environment may differ, but the decision state is the same: The order waits for an approving employee to act.
Test the buyer first. Log in as an employee with the Buyer role and place an order that uses a payment method other than **Cash on delivery**. The order should continue normally. Then place an order with **Cash on delivery**. This order should be held for approval.
Then log in as an employee with the approving role and check that the pending order appears for decision.
This storefront check is the proof that the feature activation, role assignment, payment method, and approval rule work together.
## Example: Approval Above EUR 5,000
The previous exercise used a payment method condition. Approval rules can also use order-value conditions. The next example shows the same approval model with a spending threshold.
A customer wants regular buyers to order freely up to EUR 5,000. Anything above that amount must be approved by the Management role.
In the company account, confirm that two roles exist: **Buyer** and **Management**. The Buyer role can place orders. The Management role can approve orders.
In the storefront company account, create an approval rule: orders from the Buyer role need approval from the Management role when the order value is above EUR 5,000.
Now a buyer ordering for EUR 1,200 checks out normally. The same buyer ordering for EUR 8,000 reaches checkout, but the order is submitted for approval. An employee with the Management role sees the pending order in the storefront, approves it, and only then does the order become binding. The customer's procurement rule is now enforced by the shop.
## Quick Check
Assuming no other approval rule applies, an approval rule requires approval from the Management role for buyer orders above EUR 5,000. A buyer places an order for EUR 1,200. What happens?
The order completes normally, because it is below the threshold.
The order is always submitted for approval, regardless of the amount.
The order is rejected because the buyer lacks order permission.
## Common Pitfalls
Approval issues are usually caused by a mismatch between the rule, the roles, and the storefront test user. Start there before assuming the module is broken.
### Pitfall 1: Requiring Approval for Everything
If every order needs approval, approvers become a bottleneck and buyers lose speed. Use spending thresholds when the customer only needs sign-off for larger or more sensitive orders.
### Pitfall 2: No Role Can Approve
An approval rule is useless if no active employee has the approving role. Pending orders will wait with no one able to decide. Ensure at least one active employee can approve before you test the buyer flow.
### Pitfall 3: Confusing Approval With Permissions
Permissions decide whether an employee may place an order at all. Approval decides whether a placed order needs sign-off. A buyer still needs the relevant order permission before the approval flow can apply.
### Pitfall 4: Not Testing Both Sides
Order Approval can be active but still fail in practice because the wrong employee, role, payment method, or condition value was used. Always test as both the buyer and the approver in the storefront.
### Pitfall 5: Expecting Quote Negotiation
Order Approval controls whether an order needs sign-off. It does not negotiate prices. If the customer needs a back-and-forth price discussion before ordering, use Quote Management instead.
## Summary
In this learning unit, you learned:
- Why B2B ordering may need approval before an order becomes binding.
- How approval rules link roles that can approve orders with roles whose orders need approval.
- How to prepare an approving role before creating an approval rule.
- How custom conditions, including spending thresholds, let specific ordering situations stop for sign-off.
- How to configure approval rules in the storefront company account after Order Approval is active.
- How to verify the approval flow from both storefront perspectives.
With this approval setup, B2B customers can enforce internal purchasing rules directly in the checkout flow.
Next, you will handle a different kind of pre-purchase control: quote requests, where the price itself is negotiated.