If you're encountering Rule Builder and Flow Builder for the first time in Shopware 6, confusion is almost inevitable. Both sound like automation, both are located close to each other in the admin panel, and both intervene in processes. Yet, they do something fundamentally different. That's precisely where it gets interesting. Because those who clearly separate the two build shops that react intelligently, instead of freezing up like a disgruntled printer at every minor exception.
In Shopware 6, the Rule Builder is where you define conditions. It determines when something should apply. The Flow Builder is where you define reactions. It decides what should happen when an event occurs. It sounds simple, but it's a real game-changer in everyday use. Once you understand the principle, you can restrict payment methods, control shipping methods, strategically apply discounts, automate emails, set tags, generate documents, and neatly organize background processes. In short, your shop will finally have some manners.
If you want to delve deeper into the official documentation, it's worth taking a look at the German Shopware documentation for the Rule Builder . There you'll clearly see how many places rules can be used in Shopware. And that's precisely the first important point for this article: rules aren't just a nice-to-have feature, but rather the logic layer for many decisions in the shop.
Why Rule Builder and Flow Builder are so often confused
The confusion arises because both tools operate using logic. They combine conditions, define cases, and think in if-then patterns. This feels similar. However, the core task is different. The Rule Builder evaluates a situation. The Flow Builder processes an event. Therefore, the difference is not cosmetic, but architectural.
An example makes this immediately clear. You want the payment method "purchase on account" to be available only to B2B customers with orders over €250. This is a classic job for the Rule Builder. You define the customer group and the minimum order value as conditions. Done. But you also want an internal message to be automatically sent after an order with exactly these conditions is placed, a tag to be set, and a back-office employee to follow up. Now the Flow Builder comes into play. First the condition, then the action. First the evaluation , then the process.
What the Rule Builder in Shopware 6 really does
The Rule Builder is the tool for decision logic. It checks data, contexts, and states. These include, for example, customer group, delivery country, postal code, shopping cart value, included products, payment method, shipping method, or specific properties of individual items. The rule itself does not actively trigger anything. It is available and is used elsewhere, such as for shipping methods, payment methods, promotions, prices, or in the Flow Builder.
That's precisely why the Rule Builder is the underestimated foundation in many projects. Setting it up properly saves time, discussions, and rework later on. In its official documentation, Shopware lists typical use cases, including payment and shipping method availability, shipping costs, promotions, discounts, extended pricing, and even its use in flows. This is no small feat. It's the logical control center for your day-to-day business.
Typical tasks for the Rule Builder
The Rule Builder is powerful when your shop needs to differentiate between situations. This is especially true when conditions determine whether a function is visible, allowed, charged, or blocked. This is precisely where Shopware excels. You can create rules for standard cases and refine them for special cases without needing a plugin or custom code each time. This is what makes the builder so valuable for merchants and agencies.
Typical use cases include free shipping above a certain order value, express shipping only for specific postal codes, payment by invoice only for authorized customer groups, special shipping for marked products, discounts for specific product groups, or prices depending on customer type and order quantity. This is invaluable in B2B projects because it allows you to structure complex approvals without writing code. If you work with customer groups, tiered pricing, and segmented offers, our article on Shopware B2B features with tiered pricing, quantity discounts, and customer groups is also relevant.
What matters when it comes to good rules
A good rule is specific, unambiguous, and reusable. Many shops make the same mistake here. They create ten similar rules with cryptic names like "Test 1 new," "Test 2 final," or "Shipping today really final." Frankly, that's a direct path to configuration chaos. Name your rules so that their purpose is immediately clear. For example, "Payment by invoice B2B from €250" or "Shipping by freight carrier only on one day - special delivery." You don't want to be puzzling over them later like trying to open a Kinder Surprise egg without the surprise.
Priority is also crucial. In the Rule Builder, it determines which rule takes precedence when multiple variations are involved. Especially with shipping methods and discounts, this can make the difference between elegant and embarrassing. If standard and special shipping seem possible simultaneously, you must prioritize carefully. Otherwise, you'll get results that are technically logical but utter nonsense from a business perspective.

Flowbuilder vs. rulebuilder in Shopware – Shopware – for merchants, developers, and customers – ⚙️Rule Builder vs. Flow Builder in Shopware 6 – Differences, Interaction and Real-World Practical Tips🔄
What the Flow Builder in Shopware 6 really does
The Flow Builder operates on an event-driven basis. It's not about abstract validity, but rather a concrete trigger. An order is created, a payment is received, a customer registers, a status changes, a document is generated, or an external trigger is triggered. Based on this event, the Flow Builder executes predefined actions. It actively reacts to something that happens.
The German Shopware documentation for Flow Builder describes it clearly: Flow Builder automates business processes without requiring programming knowledge and can further specify events with rules. That's the key point. A flow starts with a trigger, optionally checks conditions, and then executes actions. It's not a competitor to Rule Builder, but rather its natural partner.
Typical tasks for the Flow Builder
The Flow Builder is powerful when you need your shop to perform actions. This includes sending emails, generating documents, changing statuses, adding or removing tags, setting custom fields, switching customer groups, enabling download rights, or triggering a third-party system via webhook. According to the documentation, since Shopware 6.5.3.0, custom triggers from other applications can also be integrated. This is particularly useful if your shop connects to ERP , CRM , shipping, or marketing tools.
In practice, this means, for example: As soon as an order is received, you automatically generate the invoice, send it by email, assign an internal tag for sales, and trigger a follow-up process in a third-party system via webhook. Or, when a customer registers, you assign a tag based on their country. Or, when digital products have been paid for, you automatically activate download rights. This is operational automation that noticeably saves time.
Flow is not a gut feeling, but a chain of reactions.
A good flow consists of four parts. First, the trigger. Second, optional conditions. Third, the actual action. Fourth, if necessary, a delay. This last point is often overlooked. Not every action should happen immediately. Sometimes you want to send an email hours later, trigger a reminder after a few days, or deliberately start a process with a time delay. Shopware supports such delayed actions directly in the Flow Builder. This is practical because it allows you to implement simple follow-ups without additional tools.
If you're generally interested in the operational side of Shopware, our article on the Shopware 6 backend with a clear plan and quick results might also be of interest to you. Automation thrives on a clean and well-structured admin interface.
The most important difference in a sentence
The Rule Builder decides whether something applies. The Flow Builder decides what happens.
That's really all you need to remember about the basic logic. But since we don't want to just stick to platitudes, let's sharpen things up a bit. Rules are reusable logic building blocks. Flows are processes triggered by events. You can assign rules in many places within the shop. Flows are always linked to a trigger. Rules evaluate states. Flows control actions. Rules are more static in their function. Flows are more process-oriented.
This is how Rule Builder and Flow Builder work together
Now it gets interesting. In well-designed Shopware projects, both builders work hand in hand. You create the basis for decisions in the Rule Builder and use this rule as a condition in the Flow Builder. This avoids redundant logic, contradictory setups, and convoluted configurations that no one understands later. A shop shouldn't look like a shared apartment kitchen after three days of a festival. Instead, focus on a clean, organized structure.
An official example from the Shopware documentation illustrates this quite well. It describes how to make an item orderable only once per customer. First, a rule is created in the Rule Builder that detects whether a specific item is in the shopping cart. Then, an existing order flow is extended in the Flow Builder, this rule is checked as a condition, and a tag is assigned to the customer if the condition is met. Further rules can then be used to control how the shop handles customers who already have this tag. This is exactly what good teamwork looks like.
For concrete examples, you can look at both the sample rules for the Rule Builder and the sample flows for the Flow Builder . These two resources are especially helpful if you want to quickly put theory into practice.
Practical example 1, B2B order with internal forwarding
You run a B2B shop and want to handle high-volume orders differently than small orders. In the Rule Builder, you define a rule with the conditions: customer group "Merchant" and shopping cart value greater than €1000. You can then use this rule to restrict certain payment methods or display special conditions.
In the next step, you create a trigger in the Flow Builder based on a placed order. You use the B2B rule as the condition. If it's true, the flow sends an internal email to sales, sets a tag like "High Value Order," optionally generates a document, or calls a CRM via webhook. The result is clean. One rule, multiple uses. Exactly how it should be.
Practical example 2: Special shipping for marked products
In the Rule Builder, you define that products with a specific tag or custom field require a special shipping method. This allows you to hide standard shipping and activate special shipping. This is the decision-making level. In the Flow Builder, you then react to orders containing precisely these products. The flow can inform the warehouse, trigger a shipping partner, set an internal tag, or change a status. This connects shop logic and operational processing.
If you generally want to delve deeper into technical Shopware setups, our article on Headless Commerce with Shopware 6 and clean API connection is also a good next step, because it clearly demonstrates how important clean system logic is for later integrations.
Practical example 3, products that can only be ordered once
The official example from the documentation is quite charming for memberships, limited editions, or specific promotional items. First, you create a rule in the Rule Builder that detects whether the item in question is in the shopping cart. Then, in the Flow Builder, you check whether this rule applies when an order is placed and assign a tag to the customer. Afterward, you can use further rules to prevent customers with this tag from repurchasing the item or seeing specific shipping methods. This is a powerful example of how rules drive decisions and flows safeguard processes.
Practical tips for your everyday life with both builders
1. First build the business logic, then the process.
Many people jump straight into the Flow Builder because actions are more visible. Understandable. Emails, tags, and status changes simply make more noise than a background condition. However, the reverse order is smarter. First, clarify the logic in the Rule Builder. Who is affected? Under what conditions? What exceptions exist? Only when that's clear should you build the process in the Flow Builder. Automation and efficiency with Shopware 6 are well explained here.
2. Avoid duplicate conditions
If you replicate the same condition multiple times in different flows, your maintenance effort increases unnecessarily. Instead, create reusable rules. This way, you change the logic in one place and benefit from it in several others. This saves errors and makes the shop easier to maintain.
3. Use clear naming conventions
Especially in larger projects, you need organization. Names with a prefix and purpose have proven effective. For example, RB Shipping Special Shipping Day or FB Order B2B High Value Info Sales. It sounds dry, but it saves a lot of hassle later. Nobody wants to guess which flow is the right one when an urgent change is needed. Especially not on a Monday morning before their first coffee.
4. Test rules early and realistically.
The preview mode in the Rule Builder helps you test conditions. According to Shopware, this mode is available for Rise and higher. Use it with real orders, realistic shopping carts, and different customer types. Don't just test the desired scenario, but also the annoying exceptions. That's precisely where the errors that later lead to support tickets are hidden.
5. Set priorities consciously
Especially with shipping and discounts, you need to know which rule takes precedence. If standard and special shipping are configured in parallel, unclear prioritization can lead to odd results. This also applies to mutually exclusive actions. Therefore, briefly document why a rule has a priority of 1, 2, or 10. Your future self will silently nod in gratitude.
6. Keep flows short and focused.
A flow should be a clear process, not a chaotic collection point for every idea that pops up during the regular meeting. If a flow becomes too long, break it down into functional areas, such as order processing, payment, registration, or returns . Small, focused flows are easier to review, modify, and understand.
7. Think processes through to the end.
A workflow that simply sends an email can be helpful. It becomes even more effective when you consider the entire process. Who receives the information? Does a document need to be generated? Does the ERP system require a notification? Should a tag be set? Does a status need to be changed? Automation is most beneficial when it actually reduces follow-up work and doesn't just create a visually appealing interface.
8. Use tags consciously
Tags are small but powerful tools in Shopware. They often connect the Rule Builder and Flow Builder in a surprisingly elegant way. A flow can set a tag, and a rule can evaluate that tag. This creates chains of actions that allow you to segment customers, orders, or products in a targeted manner. The only important thing is not to use tags excessively. Otherwise, your admin area will eventually resemble a wardrobe where everything is labeled, yet nothing can be found quickly.
When you need the Rule Builder and when you need the Flow Builder
If you need to make a decision in the frontend or during configuration, use the Rule Builder. Whether something needs to be visible, allowed, or calculated, it's almost always the right starting point. Typical keywords include availability, segmentation, restrictions, pricing logic, discount logic, shipping logic, and payment logic.
If you need a workflow following an event, use the Flow Builder. It's the right tool if you want something to happen after registration, ordering, payment, or a status change. Typical keywords include notification, document, status change, tagging, approval, delay, and webhook.
In many real-world scenarios, you need both. And that's the good news. You don't have to choose like between pizza and pasta. Shopware delivers both, and together they usually taste much better.
In conclusion, if you want to get straight to the point
Rule Builder and Flow Builder in Shopware 6 are not two versions of the same tool. They solve different tasks and only become truly powerful when used together. The Rule Builder checks conditions and creates the logical basis for decisions in the shop. The Flow Builder reacts to events and executes actions. Once you consider them as a team, your processes become clearer, more scalable, and easier to maintain.
For shops with multiple shipping methods, B2B rules, special approvals, CRM or ERP integration, and growing order volumes, this interplay is often not a nice extra, but pure daily business. Clearly separating the logic saves on support, reduces errors, and accelerates processes. And yes, that ultimately benefits revenue, conversion rates, and peace of mind. Especially peace of mind.
If you want to delve deeper into Shopware as a system, take a look at our overview of Shopware 6 as an e-commerce platform. There you'll find a broader context in which Rule Builder and Flow Builder operate.
I'd really like to know how you both currently use the builder. Do you primarily deal with shipping logic, payment methods, B2B approvals, or internal processes? Or has a poorly built flow ever made your day, like, "Surprise, 400 emails are going out today!"? Share your example or question in the comments. It's precisely in these kinds of real-world scenarios that Shopware becomes truly fascinating.
Who wrote this post
Storetown Media is a Shopware agency based in Tornesch near Hamburg. We use Rule Builder and Flow Builder daily in client projects – mostly to map processes that previously would have required a plugin. What can be achieved with them and where their limitations lie is explained above in this article.






















{% endif %} {% if title and title != "" %}
{{ title }}
{% endif %} {% if excerpt and excerpt != "" %}