Using Shopware 6 Rule Builder for Dynamic Shipping Rules Based on Customer Group

Problem & Takeaway

A store owner wants to offer free shipping only to customers in the VIP group, while all other shoppers pay standard rates. Writing a custom plugin or editing PHP controllers for each shipping scenario adds development overhead and maintenance risk. Shopware 6’s Rule Builder lets administrators define such conditions through a visual interface and attach them to shipping rules, delivering the needed flexibility without custom code.

What Is the Rule Builder?

The Rule Builder is a UI‑driven rule engine that ships with Shopware 6. Administrators combine data points—such as cart total, customer group, date, or product stock—using AND/OR logic to form a condition. Each rule points to an action (e.g., a discount, free shipping, or hiding a product). At runtime the core RuleChecker service evaluates the condition and injects the result into the relevant controller, so no PHP changes are required.

Worked Example: Free Shipping for VIP Customers

1. Prerequisites: a local Shopware 6 development environment (Docker) with admin access and CLI access to the container. Run the container (requires Docker daemon and a user that can execute docker):

   docker run -d -p 8080:80 shopware/development

2. Log in to the administration at http://localhost:8080 using the admin credentials.
3. Create the rule:
   • Navigate to Marketing → Rule Builder.
   • Click + New rule.
   • Set the Condition to Customer group = VIP (select the group from the dropdown).
   • Choose the Action “Free shipping”.
4. Assign the rule to a shipping rule (e.g., “Free shipping VIP”) under Shipping → Shipping rules.
5. Save the shipping rule.
6. Clear the cache so the RuleChecker picks up the new configuration (run inside the container as a user with filesystem write permission):

   php bin/console cache:clear

Verification: open the storefront, log in as a customer assigned to the VIP group, add a product to the cart, and proceed to checkout. The shipping cost should show as zero. For a non‑VIP customer, the standard shipping fee should appear. If the free shipping does not apply, check that the rule is active in the Rule Builder list and that the cache was cleared.

Performance & Extensibility Trade‑offs

Each request triggers the RuleChecker to evaluate all active rules that apply to the current context (price, shipping, visibility, flow). A rule set with many nested conditions can increase evaluation time, especially on high‑traffic stores. Profiling rule execution (e.g., with Xdebug or the Shopware performance toolbar) is advisable before deploying large collections. The feature is extensible: developers can add custom condition types by implementing Shopware\Core\Framework\Rule\ConditionInterface and tagging the service with shopware.rule.condition in services.yaml. After clearing the cache, the new condition appears in the Rule Builder dropdown, allowing richer logic without touching core code.

Closing & Actionable Steps

Start by translating a concrete business requirement into a simple rule (e.g., “VIP group → free shipping”). Verify the outcome in the storefront, then monitor performance if you add more rules. When the built‑in conditions are insufficient, create a custom condition or action class, register it via the DI container, clear the cache, and test in a staging environment first. This approach keeps shipping logic maintainable, avoids custom development, and ensures consistency across price, shipping, and visibility rules.