Shopware Rule Builder: Conditional Discounts and the Limits of Declarative Logic

Shopware's Rule Builder lets you attach conditional behavior—discounts, shipping methods, payment visibility—to storefront requests without deploying a custom plugin. The useful takeaway is that it works well for straightforward, data-driven conditions, but every rule is evaluated on each request, so treat it as a configuration layer with performance boundaries rather than a replacement for all custom logic.

Worked Example: A €100 Germany Discount

Suppose you want to give customers a 10% discount when the cart total reaches €100 and the billing address is in Germany. In the Shopware admin, navigate to Marketing > Rule Builder and create a new rule. Add two conditions: Cart total amount greater than or equal to 100, and Billing country equal to Germany. Then add the action Discount with a percentage value of 10. Save and activate the rule.

This configuration is declarative: you describe the desired state, not the procedure. Shopware evaluates the rule during cart calculation. If the conditions match, the discount action is applied automatically. No custom PHP code is required for the rule to take effect.

How Rule Evaluation Works

Rules are not compiled into static logic. On each storefront request that touches the cart—adding an item, changing quantity, entering an address—Shopware loads the active rules and evaluates their conditions against the current context. The context includes the sales channel, cart contents, customer data, and billing or shipping addresses.

Because evaluation happens per request, the cost scales with two factors: the number of active rules and the complexity of each rule's conditions. A rule with five conditions is cheaper than a rule with fifty, but both are re-evaluated every time the cart changes. On high-traffic storefronts, many active rules with nested conditions can increase response time for cart and checkout pages.

Version note: the Rule Builder UI and API are stable from Shopware 6.4 onward. Older versions may lack certain condition types or the underlying RuleBuilder service, so verify your installation before designing complex rule sets.

Limits and Common Mistakes

Overlapping Rules and Unexpected Precedence

When multiple rules match the same cart, Shopware applies all matching actions. Overlapping rules can cause unexpected precedence, especially when conditions are not mutually exclusive. If one rule grants a 10% discount and another grants a 5% discount on the same cart, both apply, which may produce an unexpected combined result. Design rules so their conditions are either mutually exclusive or intentionally cumulative.

Inactive Rules

A common oversight is saving a rule without activating it. In the Rule Builder list, check the status column. An inactive rule is ignored during evaluation. If a discount does not appear in the cart, verify the activation status before debugging conditions.

Custom Fields and Data Availability

Rule conditions can only reference data that Shopware exposes to the rule context. If you check a custom field that is not populated in the current sales channel or not mapped to the rule context, the condition evaluates to false. Confirm that the field exists on the entity and is available in the storefront API before relying on it.

Core Domain Logic Boundaries

The Rule Builder cannot perform arbitrary database writes, create custom entity relations, or alter core business logic that falls outside the built-in condition and action types. If your requirement involves persisting new data, integrating with an external system, or changing the fundamental calculation algorithm, a custom plugin remains necessary.

Verifying Rule Registration and Performance

To confirm that a rule is registered in the system, run the following CLI command from the Shopware project root:

bin/console rule:list

Required permissions: the CLI user must have filesystem access to the Shopware installation. Expected check: the rule name appears in the output list. If it is missing, the rule was not saved correctly or the wrong environment is targeted.

For performance inspection, enable the Shopware profiler (typically available in the dev environment) and load a storefront cart page. Inspect the timeline for rule evaluation entries. If rule evaluation dominates the response time, reduce the number of active rules or simplify condition logic.

When to Reach for Custom Code

Use the Rule Builder when the logic is a simple mapping from cart or customer state to a standard action—discount, shipping method selection, payment method visibility. Use a custom plugin when the behavior requires new data structures, external side effects, or calculations that the built-in actions cannot express. The boundary is not about difficulty; it is about whether the decision can be expressed as a condition-action pair over existing Shopware data.