Use Shopware 6 Rule Builder for pricing, not a plugin, until you hit its limits

The problem: a promotion request that shouldn't need a deploy

Marketing wants a cart-value discount live tomorrow. Engineering does not want a code change, a plugin release, and a deployment window for a rule that will change again next week. In Shopware 6 the practical decision is often to model that logic declaratively with the Rule Builder instead of writing a custom plugin.

The Rule Builder is an admin UI for defining conditions and actions. Conditions can reference cart, customer, date, etc. Actions can be discounts, payment or shipping restrictions. Rules are stored as JSON entities and evaluated on the storefront using Symfony ExpressionLanguage. That means no PHP for the common cases, and rule changes stay in the admin.

Why Rule Builder is the default engineering choice for promotions

Centralizing rule management in the admin reduces deployment overhead. Non-developers can adjust thresholds, dates and scopes without a pull request. Because rules are data, they can be versioned via the admin API and exported between environments.

The trade is scope. The Rule Builder is declarative. It cannot execute arbitrary PHP or call external APIs directly. Complex calculations, custom rounding, or service calls require a Flow Builder extension or a custom plugin.

Worked example: cart over 100 EUR gets 10% off

This illustrates the typical flow for a cart-value promotion.

Create the rule

In the admin go to Settings > Rule Builder. Create a new rule, e.g. name "Cart over 100 EUR". Add a condition group with operator AND. Add condition "Cart total amount" with operator ">=" and value 100. Save. The rule is now a reusable condition set.

Assign the rule to a promotion

Go to Marketing > Promotions. Create a promotion, set the Rule Builder rule created above as the promotion condition. In the promotion discounts section add a percentage discount of 10%. Assign the promotion to the sales channel and set validity dates. The promotion references the rule; the rule defines when it applies.

On the storefront, when a cart is calculated the Rule Checker evaluates active rules for the current context. If the cart total meets the condition, the promotion discount is applied in the cart summary.

Limitations to plan for

Rule evaluation runs on many storefront requests. A large rule set, especially with heavy conditions like full-text search or large collections, can increase response time. Keep the rule count low and prefer indexed fields where possible.

The Rule Builder cannot replace custom pricing logic. If you need custom PHP, external service calls, or calculations beyond the built-in operators, you will need a plugin or Flow Builder. Workarounds with multiple rules tend to become hard to maintain.

How to verify in a local dev environment

Local verification should confirm the rule exists, is linked to the promotion, and is evaluated without obvious overhead.

• Admin UI check. Log into the admin, open Settings > Rule Builder and confirm the rule name, condition type, operator and value match intent. Then open Marketing > Promotions and confirm the promotion references the rule and the discount action.
• API check. With an admin API access token that has read access to rules, run a GET request to /api/v2/_action/rules from a terminal or API client. Inspect the returned rule entities for the condition and action fields you configured in the UI. This verifies the data model matches the UI.
• Profiler check. Enable the Symfony profiler for the storefront in your dev environment. Load a cart page and open the profiler. Look for the RuleChecker section. Monitor evaluation time and rule count for a modest rule set. If evaluation time grows, consider consolidating rules or removing unused ones.

These checks confirm the rule is stored correctly and is being evaluated. Version behavior can vary across Shopware 6.x releases, so verify against your target version.

Actionable closing

Use Rule Builder for declarative, marketing-owned promotions like cart-value thresholds, customer group restrictions, and date windows. Move to a plugin when you need custom PHP, external calls, or calculations outside the built-in operators. Keep the rule set small, review it regularly, and monitor evaluation cost in the profiler.