Shopware Flow Builder: Automate Workflows Without Code

Shopware’s Flow Builder is a visual automation tool that lets you create business workflows without writing code. It works on a trigger-action model: when something happens in your store (an order is placed, a customer registers, inventory hits zero), Flow Builder executes a sequence of actions you define – send an email, tag a customer, change an order status, call a webhook, or dozens of other operations.

For merchants running on Shopware 6, Flow Builder replaces what used to require custom plugins or manual processes. Order routing, customer segmentation, notification chains, fraud flags, inventory alerts – these are all workflows you can build and modify directly in the admin panel without a developer.

This guide covers how Flow Builder actually works in practice, what it handles well, where it falls short, and how to get the most from it without creating a maintenance headache.

Boost Your Business With Shopware Flow Builder

The real value of Flow Builder is not any single automation. It is the compound effect of removing manual steps from your daily operations. Every workflow you automate is a task someone on your team no longer has to remember, execute, and verify.

A mid-size merchant typically runs 15 to 30 active flows covering order processing, customer communication, inventory management, and internal notifications. Each flow saves minutes per day. Collectively, they can recover 10 to 20 hours of staff time per week – time that was previously spent on repetitive operational tasks.

More importantly, automated workflows execute consistently. They do not forget to send the shipping notification at 2 AM. They do not miss the VIP tag on a customer who just crossed the $10,000 lifetime spend threshold. They do not skip the fraud check on a high-value order because the team was busy.

Key Takeaways

• Flow Builder uses a trigger-condition-action model. You select what event starts the flow, optionally add conditions to filter when it should run, and define what actions to execute.
• Over 40 built-in triggers cover orders, customers, products, checkout, and system events. Combined with conditions and multiple action types, you can build complex workflows without code.
• Flow Builder handles sequential actions well but does not support branching logic (if-then-else) natively. For complex conditional logic, you need multiple flows or custom flow actions.
• Performance matters at scale. Flows that trigger on high-frequency events (like page views or cart updates) or execute heavy actions (like API calls or large data operations) can impact store performance.
• Custom flow actions let developers extend Flow Builder with new triggers and actions, making it a genuinely extensible automation platform rather than a closed system.
• Flow Builder and Rule Builder are complementary tools, not competitors. Rule Builder defines conditions (who, what, when). Flow Builder defines reactions (then do this). Many effective automations use both together.

How Flow Builder Works

Triggers

Every flow starts with a trigger – an event that occurs in your Shopware store. When that event fires, Flow Builder evaluates the flow’s conditions and, if they match, executes the defined actions.

Trigger Category	Examples
Order	Order placed, order status changed, payment status changed, order delivered
Customer	Customer registered, customer login, customer group changed, customer deleted
Checkout	Checkout completed, checkout order placed
Product	Product stock updated, product price changed
Contact	Contact form submitted
Newsletter	Newsletter registration, newsletter unsubscribe
System	User recovery requested

Each trigger provides context data – the order object, customer details, product information – that you can use in conditions and actions. An order.placed trigger gives you access to the order total, line items, customer information, shipping method, and everything else associated with that order.

Conditions

Conditions filter when a flow should execute. A trigger might fire thousands of times a day, but your flow should only act on specific cases.

Condition Type	Examples
Order	Order amount greater than X, order contains product from category Y, shipping method is Z
Customer	Customer group is VIP, customer registered more than 30 days ago, customer country is US
Product	Product stock below X, product is in category Y
Cart	Cart line item count greater than X, cart includes specific product
Custom	Tag is present, custom field equals value

Conditions support AND/OR logic. You can combine multiple conditions to create specific targeting – for example, “order total over $500 AND customer is in group wholesale AND shipping country is not US.” This gives you fine-grained control without needing separate flows for each scenario.

Actions

Actions are what Flow Builder does when a trigger fires and conditions are met.

Action Category	Specific Actions
Communication	Send email, send custom email template
Order Management	Set order status, set payment status, set delivery status, generate document
Customer Management	Add tag to customer, remove tag, change customer group, set custom field
Product/Inventory	Set product stock, add product tag
Internal	Add internal note, send webhook, stop flow
Advanced	Execute script (App Scripts), delay action

Actions execute sequentially in the order you define them. You can chain multiple actions – for example, when a VIP customer places an order over $1,000: (1) set order status to priority, (2) send notification email to sales team, (3) add “high-value-order” tag to the order, (4) send webhook to your CRM.

The Delay Action

The delay action pauses execution for a specified duration before continuing with the next action. This is genuinely useful for time-based workflows:

• Send a review request email 14 days after order delivery
• Add a “returning customer” tag 30 days after first purchase if no second order exists
• Send a reorder reminder 60 days after purchase for consumable products

Delays are persistent – they survive server restarts and are stored in the database. If your server goes down during a delay period, the action will still execute when the delay expires after the server comes back up.

Real-World Automation Examples

1. VIP Customer Auto-Tagging

Trigger: Order placed Condition: Customer lifetime spend exceeds $5,000 Actions:

1. Change customer group to “VIP”
2. Add tag “vip-customer”
3. Send email to customer with VIP welcome and benefits
4. Send notification to sales team about new VIP customer
5. Call webhook to update CRM record

This flow runs on every order but only acts when the cumulative spend threshold is crossed. The customer gets upgraded automatically, notified of their new status, and your sales team knows to give them priority attention.

2. Fraud Detection Flagging

Trigger: Order placed Condition: Order total exceeds $2,000 AND billing country differs from shipping country AND customer account is less than 7 days old Actions:

1. Set order status to “review required”
2. Add tag “fraud-review” to order
3. Send notification email to fraud review team
4. Add internal note with flag details

This does not replace a dedicated fraud detection system, but it catches common red flags and ensures high-risk orders get human review before fulfillment.

3. Automated Reorder Reminder

Trigger: Order delivery status changed to “delivered” Condition: Order contains products from category “consumables” Actions:

1. Delay 45 days
2. Send reorder reminder email with direct links to previously purchased products

Timing the reminder based on product type (consumables typically need replenishment) drives repeat purchases without manual intervention. The delay action makes this possible without any cron jobs or custom code.

4. Low Stock Alert Chain

Trigger: Product stock updated Condition: Stock quantity falls below 10 Actions:

1. Send email to purchasing team with product details and current stock level
2. Add tag “low-stock” to product
3. Send webhook to inventory management system

When stock drops further: Condition: Stock quantity reaches 0 Actions:

1. Send urgent email to purchasing manager
2. Add tag “out-of-stock” to product
3. Send webhook to update product availability in external channels

This uses two separate flows on the same trigger with different conditions. The first flow gives your team time to reorder. The second escalates when stock actually runs out.

5. B2B Customer Onboarding Sequence

Trigger: Customer registered Condition: Customer group is “B2B pending” Actions:

1. Send welcome email with account setup instructions
2. Add tag “onboarding-started”
3. Send notification to sales team about new B2B registration
4. Delay 3 days
5. Send follow-up email with product catalog highlights
6. Delay 7 days
7. Send email with ordering guide and support contacts

This creates a basic drip sequence for new B2B registrations without needing a separate email marketing platform. The delays space out the communications naturally.

6. Post-Purchase Review Request

Trigger: Order delivery status changed to “delivered” Condition: Customer has not been tagged with “review-requested” in the last 90 days Actions:

1. Delay 14 days
2. Send review request email
3. Add tag “review-requested” to customer

The tag check prevents sending review requests too frequently to repeat customers. The 14-day delay gives the customer time to actually use the product before you ask for their opinion.

Webhook Actions and External System Triggers

Sending Webhooks

The webhook action sends an HTTP POST request to any URL you specify. The payload includes the event data from the trigger – order details, customer information, product data – serialized as JSON.

This is how you connect Flow Builder to external systems without writing a plugin. Common webhook destinations include:

• CRM systems: Push new customer registrations, VIP upgrades, or high-value orders to Salesforce, HubSpot, or Pipedrive.
• ERP systems: Notify your ERP when an order is placed, payment is confirmed, or stock needs adjustment.
• Slack or Teams: Send notifications to team channels for specific events.
• Automation platforms: Trigger Zapier, Make (Integromat), or n8n workflows for complex multi-system automations.
• Custom microservices: Call your own APIs for business logic that does not belong in the storefront.

Webhook Configuration

When configuring a webhook action, you specify the URL and the data gets sent automatically based on the trigger context. The receiving system needs to handle the JSON payload and respond with a 2xx status code.

Important considerations:

• Timeout: Webhook calls have a timeout. If the receiving system is slow, the action may fail without retrying.
• Error handling: Failed webhooks do not retry by default. If the receiving system is down, the webhook is lost. For critical integrations, implement an intermediary queue (like a serverless function that queues and retries).
• Security: Use HTTPS endpoints and implement signature verification on the receiving end to prevent unauthorized calls.
• Performance: Webhook calls add latency to the flow execution. If you are calling slow external APIs, this can delay subsequent actions in the flow.

Receiving External Triggers

Flow Builder processes internal Shopware events. To trigger a flow from an external system, you need an intermediary – typically an App Script or custom plugin that receives an external webhook, processes it, and dispatches a Shopware event that Flow Builder can listen to.

For example, to trigger a flow when your ERP updates inventory levels: the ERP sends a webhook to a custom endpoint in your Shopware instance, a plugin receives it, updates the product stock, and Shopware’s stock.updated event fires, triggering your Flow Builder flow.

Common Workflow Recipes

Recipe 1: Order Processing Pipeline

Create a series of flows that automate the full order lifecycle:

Flow A – Order Received: Trigger: Order placed Actions: Send confirmation email, set status to “processing,” notify warehouse via webhook

Flow B – Payment Confirmed: Trigger: Payment status changed to “paid” Actions: Generate invoice document, send invoice email, set order status to “ready for picking”

Flow C – Order Shipped: Trigger: Delivery status changed to “shipped” Actions: Send shipping confirmation with tracking number, update CRM, start delivery follow-up delay

Flow D – Order Delivered: Trigger: Delivery status changed to “delivered” Actions: Delay 14 days, send review request, delay 45 days, send reorder reminder (for applicable products)

These four flows cover the entire order lifecycle with no manual intervention for standard orders. Exception flows (cancellations, returns, payment failures) run alongside them with their own triggers and conditions.

Recipe 2: Customer Lifecycle Segmentation

Automatically segment customers based on behavior:

Flow A – New Customer Welcome: Trigger: Customer registered Actions: Send welcome email, add tag “new-customer,” delay 7 days, send educational content email

Flow B – First Purchase: Trigger: Order placed Condition: Customer has no previous orders (tag “first-order” not present) Actions: Add tag “first-order,” remove tag “new-customer,” send first purchase thank-you email

Flow C – Repeat Customer: Trigger: Order placed Condition: Customer already has tag “first-order” Actions: Add tag “repeat-customer,” check if VIP threshold is met, update customer group if applicable

Flow D – Win-Back: Trigger: Scheduled (requires custom trigger or App Script) Condition: Customer last order more than 90 days ago Actions: Send win-back email with incentive, add tag “win-back-sent”

Recipe 3: Inventory Management Automation

Flow A – Low Stock Warning: Trigger: Product stock updated Condition: Stock below reorder point (custom field) Actions: Email purchasing team, add low-stock tag, webhook to supplier portal

Flow B – Out of Stock: Trigger: Product stock updated Condition: Stock equals zero Actions: Email operations manager, hide from storefront (optional), notify marketplace channels via webhook

Flow C – Back in Stock: Trigger: Product stock updated Condition: Stock was zero and is now greater than zero Actions: Remove out-of-stock tag, send back-in-stock notification to subscribed customers, re-enable on marketplaces

Recipe 4: Geographic Routing

Flow A – EU Orders: Trigger: Order placed Condition: Shipping country is in EU Actions: Set custom field “warehouse” to “EU-fulfillment,” send to EU warehouse webhook, generate EU-compliant invoice

Flow B – US Orders: Trigger: Order placed Condition: Shipping country is US Actions: Set custom field “warehouse” to “US-fulfillment,” send to US warehouse webhook, generate US invoice format

Flow C – International Orders: Trigger: Order placed Condition: Shipping country not in EU and not US Actions: Set status to “international-review,” notify international shipping team, add tag “customs-required”

Custom Flow Actions

Developers can extend Flow Builder by creating custom triggers, conditions, and actions through Shopware plugins or App Scripts. This is what makes Flow Builder an extensible platform rather than a closed tool.

Creating Custom Actions

A custom action is a PHP class that implements Shopware’s FlowAction interface. You define what the action does, what parameters it accepts, and which triggers it is compatible with. Once registered, it appears in the Flow Builder UI alongside built-in actions.

Common custom actions we have seen in production:

• Generate PDF packing slip with custom layout
• Create task in project management tool (Asana, Monday, Jira)
• Calculate and apply loyalty points
• Send SMS via Twilio or MessageBird
• Update external product feed (Google Merchant, Facebook Catalog)
• Sync order to accounting software (QuickBooks, Xero)
• Create shipping label via carrier API (DHL, UPS, FedEx)

Creating Custom Triggers

Custom triggers let Flow Builder react to events that Shopware does not track natively. You define a new event, dispatch it from your code, and it becomes available as a trigger in Flow Builder.

Examples:

• Subscription renewed: If you have a subscription plugin, dispatch an event when a subscription renews so flows can send confirmation emails, update CRM records, etc.
• External webhook received: Create an endpoint that receives webhooks from external systems and dispatches them as Shopware events.
• Scheduled events: Dispatch events on a schedule (daily, weekly) to trigger time-based flows like reporting or cleanup tasks.

App Scripts for Lightweight Customization

For simpler customizations, Shopware’s App Script system lets you add custom logic in Twig templates without writing a full plugin. App Scripts can be used for custom actions that modify data, perform calculations, or format output without the overhead of a PHP plugin.

This is useful for small automations that do not justify a dedicated plugin – formatting data before sending a webhook, calculating a value based on order data, or transforming an email template dynamically.

Flow Builder vs Rule Builder

This is a common source of confusion. Flow Builder and Rule Builder are complementary tools that serve different purposes.

Rule Builder defines conditions. It answers “who qualifies” or “when does this apply.” Rules are used for pricing, shipping method availability, payment method availability, promotions, and content visibility. A rule might say “customers in group wholesale who have ordered more than $5,000 in the last 12 months.”

Flow Builder defines reactions. It answers “what happens when.” Flows are triggered by events and execute actions. A flow might say “when an order is placed and the customer matches the VIP rule, send a priority notification.”

They work together. You create rules in Rule Builder to define complex conditions, then reference those rules in Flow Builder conditions. This keeps your logic DRY – define the “VIP customer” criteria once in Rule Builder, then use it across multiple flows, pricing rules, and content assignments.

Aspect	Rule Builder	Flow Builder
Purpose	Define conditions	Define reactions
Trigger	Evaluated on demand	Event-driven
Output	True/false match	Execute actions
Use cases	Pricing, shipping, promotions	Notifications, status changes, integrations
Execution	Synchronous, per-request	Asynchronous, event-based

Implementation Mistakes

1. Creating Too Many Flows for One Process

When a single business process involves multiple conditions and actions, some teams create a separate flow for each variation. A returns process might end up as 15 different flows for different return reasons, product types, and customer groups.

This becomes unmaintainable. Instead, use conditions within a single flow to handle variations, or create a small number of flows organized by process stage (return initiated, return received, refund processed) rather than by every possible combination.

2. Ignoring Flow Execution Order

When multiple flows share the same trigger, execution order matters. If Flow A changes an order status and Flow B checks that status, the result depends on which runs first. Shopware does not guarantee execution order for flows on the same trigger.

Design flows to be independent when possible. If order matters, combine dependent logic into a single flow rather than spreading it across multiple flows that race against each other.

3. Not Testing Delay Actions Thoroughly

Delay actions are easy to set up and hard to test. A 14-day delay means you do not see the result for two weeks in production. Test with short delays (minutes) in your staging environment to verify the full flow executes correctly, then adjust to production durations.

Also verify that delayed actions still make sense when they execute. A reorder reminder sent 45 days after delivery is useless if the customer already placed another order. Add conditions after the delay to check current state before executing the remaining actions.

4. Webhook Actions Without Error Handling

Webhooks fail silently. The external system goes down, the URL changes, the payload format breaks – and Flow Builder just moves on to the next action without retrying or alerting you.

For critical webhooks (order sync to ERP, inventory updates), implement monitoring on the receiving end that alerts you when expected webhooks stop arriving. Consider using a middleware service that queues and retries failed deliveries.

5. Overcomplicating Conditions

Complex AND/OR condition trees are hard to read, debug, and maintain. If your condition logic requires more than three or four criteria, consider whether a Rule Builder rule would be cleaner. Rules are reusable across flows and have their own testing interface.

Where Flow Builder Reaches Its Limits

No Branching Logic

Flow Builder executes actions sequentially. There is no native if-then-else branching – you cannot say “if condition A, do action X; otherwise, do action Y” within a single flow. You need separate flows with different conditions to handle branches.

This means a workflow like “if the customer is in the EU, generate an EU invoice; if they are in the US, generate a US invoice; otherwise, flag for manual review” requires three separate flows rather than one flow with branches.

Shopware has acknowledged this limitation, and branching may arrive in a future version. For now, plan your flows around sequential execution with conditions acting as filters, not branches.

Limited Error Handling

When an action fails (webhook timeout, email delivery failure, invalid data), Flow Builder does not offer built-in retry logic, error notifications, or fallback actions. The flow either continues to the next action or stops, depending on the failure type.

For production-critical workflows, this means you need external monitoring to detect when flows fail. Check your email delivery logs, webhook receiver logs, and order status distributions to catch flows that are silently failing.

No Visual Debugging

Flow Builder’s admin interface shows you the flow definition, but there is no execution log or visual debugger that shows you what happened when a specific order triggered the flow. You cannot trace “Order #12345 triggered Flow X, condition evaluated to true, action 1 succeeded, action 2 failed because of timeout.”

Debugging requires checking individual system logs, email logs, and webhook logs to piece together what happened. For complex flows, this is time-consuming. Maintain a test environment where you can trigger flows manually and observe results.

Performance at Scale

Every active flow adds processing overhead to its trigger event. If you have 50 flows triggered by “order placed,” every order placement evaluates all 50 flows. Most will short-circuit on conditions, but the evaluation still takes time.

For high-traffic stores processing hundreds of orders per hour, excessive flows on common triggers can cause noticeable delays. Monitor your flow execution times and consolidate flows where possible. If a flow performs heavy operations (large webhook payloads, complex data transformations), consider offloading that work to an asynchronous queue.

No Built-In Scheduling

Flow Builder is event-driven – it reacts to things that happen. It cannot initiate actions on a schedule (“every Monday at 9 AM, generate a sales report” or “every day at midnight, check for abandoned carts from the last 24 hours”).

Scheduled workflows require either a custom plugin that dispatches events on a cron schedule, an external scheduler that calls webhooks into your Shopware instance, or App Scripts with scheduled execution.

Getting the Most From Flow Builder

Start With Your Manual Processes

The best candidates for automation are tasks your team does manually every day – and sometimes forgets. Make a list of every repetitive operational task: sending order confirmations, flagging unusual orders, notifying suppliers, updating customer records. Start automating the highest-volume, lowest-complexity tasks first.

Document Your Flows

Flow Builder does not have built-in documentation. Name your flows clearly (not “Flow 1” but “VIP-Upgrade-On-Order-Over-5000”) and maintain a separate document that maps each flow to the business process it supports, who owns it, and when it was last reviewed.

As flows accumulate, this documentation becomes essential. Six months from now, when someone asks “why is this customer getting two emails after every order,” you need to be able to trace which flows are involved without clicking through every single one.

Review Flows Quarterly

Business rules change. Thresholds shift. New product categories emerge. Flows that were correct six months ago may no longer match your current operations. Schedule quarterly reviews of all active flows to verify they still reflect your business logic.

Pay special attention to:

• Threshold values (order amounts, stock levels) that may need adjustment
• Email templates that reference outdated promotions or policies
• Webhook URLs that may have changed
• Conditions that reference customer groups or categories that have been restructured

Use Tags Strategically

Tags are Flow Builder’s most versatile tool for tracking state across workflows. Use consistent tag naming conventions: “onboarding-step-1-complete,” “vip-candidate,” “review-requested-2025-q1.” Tags let one flow check what another flow has already done, enabling multi-step workflows without complex state management.

Clean up old tags periodically. A customer with 50 historical tags creates noise and can slow down tag-based condition evaluation.

Test in Staging First

Every flow should be tested in a staging environment before going live. Create test orders, customers, and scenarios that exercise each condition branch. Verify that emails send correctly, webhooks deliver the expected payload, and status changes happen in the right order.

For flows with delays, test with shortened durations to verify the full sequence. A flow that works perfectly for the first two actions but fails on the third (after a delay) will not show the problem for days in production.

Frequently Asked Questions

Does Flow Builder work with Shopware’s headless / API-first mode?

Yes. Flow Builder triggers are based on Shopware events, which fire regardless of whether the action originated from the admin panel, the storefront, or an API call. An order placed via the Store API triggers the same order.placed event as one placed through the traditional storefront. Your flows work the same way in headless implementations.

Can Flow Builder replace a dedicated marketing automation platform?

For basic automations like welcome sequences, reorder reminders, and customer segmentation, Flow Builder can handle the work. However, it lacks the sophisticated features of dedicated platforms like Klaviyo or ActiveCampaign – A/B testing, advanced segmentation, behavior-based email sequences, send-time optimization, and detailed email analytics. If email marketing is a major revenue driver, use Flow Builder for operational workflows and a dedicated platform for marketing automation.

How many active flows can Shopware handle before performance degrades?

There is no hard limit, but practical limits depend on your traffic volume and flow complexity. Stores with moderate traffic (under 100 orders per day) can run 50 to 100 flows without noticeable impact. High-traffic stores should keep flow counts lower and ensure flows on high-frequency triggers (like page views or cart updates) are minimal. Monitor your message queue length and processing times as you add flows.

Can I import/export flows between environments?

Shopware’s flow definitions are stored in the database and can be exported/imported using the admin API or migration tools. However, there is no built-in one-click export/import in the admin UI. For structured deployments, define flows in your deployment pipeline using Shopware’s migration system or API scripts to ensure consistency across development, staging, and production environments.

Does Flow Builder support multi-language emails?

Yes. When you configure an email action, you can use email templates that have translations for each of your configured languages. The system automatically selects the correct language version based on the customer’s language setting or the sales channel language. You define the template content in each language through Shopware’s email template management.

Can I trigger a flow from another flow?

Not directly. There is no “trigger another flow” action. However, you can achieve a similar effect by having Flow A perform an action (like changing an order status or adding a tag) that serves as the trigger for Flow B. This indirect chaining works but requires careful documentation to track the dependencies between flows.

What happens to delayed actions if I deactivate a flow?

If a flow is deactivated while delayed actions are pending, the behavior depends on the Shopware version. In most versions, pending delayed actions will still execute because they are already queued. Deactivating the flow only prevents new triggers from starting. If you need to cancel pending delays, you may need to clear the message queue manually.

Is there an API to manage flows programmatically?

Yes. Shopware’s Admin API provides endpoints for creating, reading, updating, and deleting flows. You can manage flow definitions, triggers, conditions, and actions through the API, which is useful for automated deployments, backup/restore, and managing flows across multiple store instances. The API follows the same entity structure you see in the admin UI.