Order backlog after sales events: bulk edit in Shopware

For Black Friday and Cyber Monday 2025, the German Retail Federation expected revenue of 5.8 billion euros (HDE). For the shop, that means a long list of orders after the sales events: they have to be marked as paid or shipped, given an invoice and a delivery note, and reported to customers. Bulk edit in Shopware handles this directly in the Administration, for up to 1,000 orders per selection (Shopware documentation). It does have quirks that become expensive at peak volume: flows can run twice, status emails go out in large numbers, and documents arrive as one merged PDF. This guide shows the sequence from filter to document, the decision on flows and emails, and the point at which a status update from the ERP or a run via the Admin API makes more sense. It is meant as preparation: if you walk through the steps in a test environment before Black Week, you do not have to learn them under time pressure the day after. Our Shopware agency supports setup and testing.

Why orders pile up after sales events

Sales events compress incoming orders into a few days, and many of those orders come with a deadline the shop does not set itself. According to the federation's forecast, around 1.6 billion euros of spending on Black Friday and Cyber Monday 2025 went to Christmas shopping (HDE). Anyone who orders a gift on these days expects the goods before the holiday and a message as soon as they are on their way. The work therefore shifts from selling to fulfillment: matching incoming payments, printing delivery notes, handing over parcels, setting statuses, creating and sending invoices.

In many shops part of this runs automatically, for example through a payment method that reports the payment status itself, or through an inventory system that reports shipping back. Another part remains manual work in the Administration: prepayments that are marked as paid after bank reconciliation, the bulk dispatch in the afternoon, canceling unpaid orders after the payment deadline. As long as there are only a few orders a day, the detail view is enough. At a peak after sales events the same manual work becomes a bottleneck, and this is exactly what bulk edit is for.

How the shop itself survives the traffic peak is covered in our article on the virtual waiting room for Black Friday. This article is about the days after, when the orders are in and have to be processed in an orderly sequence without customers receiving duplicate emails or missing invoices.

What bulk edit in Shopware can do

Bulk edit sits in the order overview of the Administration. The documentation describes it as an easy and quick way to change multiple orders at the same time (Shopware documentation). It is described there from the version for Shopware 6.4.5.0 onward; the version for 6.4.0.0 to 6.4.4.1 does not yet contain the section (Shopware documentation). Its source code sits in the open-source core of the Administration, so it is available without an additional extension (Shopware source code). At its core it covers three steps:

According to the source code, the same form also sets tags for the selected orders (Shopware source code). After sales events this is more useful than it sounds: a tag such as “Black Week” marks a batch, and the order overview filters by it. What bulk edit does not cover is also in the documentation, just in a different place: the team enters tracking numbers in the order details under shipping, and changes items and the delivery address per order (Shopware documentation). For orders the team creates itself, for example after a phone call, the approach from our article on phone and email orders in the Shopware Admin applies.

The sequence: filter, selection, status, documents

The order of the steps is not arbitrary. If you create documents first and then set the status with email dispatch, you send different attachments than the other way around, and if you open a mixed selection, you find fewer options in the status field than expected. This sequence is recommended as a working order:

1. Filter: order date set to the sales period, plus payment and delivery status, payment method, shipping method or sales channel. The filter determines which orders can enter the selection at all.
2. Select: individual orders or all orders on the page, across several pages if needed. Compare the counter above the list with the expected number.
3. Open bulk edit: the pop-up shows the selection once more. Outliers can be removed here before anything is changed.
4. Choose the status: change only the status type this pass is about, for example the delivery status “Shipped”.
5. Decide on emails: switch status emails on or off and decide whether existing documents are attached.
6. Create documents: invoice or delivery note with date and optional comment; documents that already exist are not created again.
7. Apply: the pop-up states the number of orders that will be changed. This is also where the decision on “Trigger flows” is made.
8. Download and check: load the merged PDF and use a filter for orders without documents to check that every order has its document.

Filtering and selecting without breaking the limit

The filter in the order overview is the real tool behind bulk edit. Among other things it combines order date, order status, payment status, delivery status, payment method, shipping method, sales channel, tags, products and whether documents are already attached to the order; every additional entry narrows the list (Shopware documentation). If you want to tick off shipped parcels after sales events, you do not filter for “all orders of the week”, but for paid orders with an open delivery status from the sales period and a specific shipping method.

Selection works by checkbox: individual orders or all orders on the current page, and the selection can continue across several pages. At most 1,000 orders can be selected at once (Shopware documentation). The number of selected orders is shown above the list, and as soon as orders from several pages are selected, an option appears to clear the whole selection (Shopware documentation). If the batch is above the limit, it is split, ideally along a filter such as shipping method or order date, so that it remains traceable later which pass affected which orders. The tag from the previous section helps here: if every processed batch is marked, the filter immediately shows what is still open.

Status transitions: which status is valid for the selection

An order in Shopware carries three states: the order status, the status of the payment and the status of the delivery (Shopware developer documentation). You cannot jump freely between the values. The state machine only allows defined transitions; a payment, for example, cannot be set to “Refunded” as long as it was not paid (Shopware developer documentation). For bulk edit this has a practical consequence that looks like an error at first glance.

In bulk edit, the order status can only be changed to a value that is valid for all selected orders. The documentation gives the example itself: an open order can change to “In progress” or “Canceled”, an order in progress to “Completed” or “Canceled”. If you select both together, only “Canceled” remains (Shopware documentation). So if the expected value is missing in the status field, the selection is usually mixed. The remedy is to filter for the current status before selecting.

Status emails and flows: avoiding double triggers

Two switches decide what a bulk edit does outside the database. The first is labeled “Status emails” in the form: as soon as at least one status is changed, it determines whether customers receive an email about the change. If it is off, according to the documentation no emails are sent at all, not even via a flow that is triggered by the status change and may still run (Shopware documentation). The switch therefore affects emails, not the other actions of a flow.

The second switch is called “Trigger flows” and appears when the changes are applied. The documentation justifies it with a behavior that becomes expensive at peak volume: if status emails are sent with the bulk edit, all triggers created in the Flow Builder can be executed for all changes.

Under certain circumstances, this can lead to flows being executed twice.

Shopware documentation, Orders: Overview, section Trigger Flows with this bulk edit

The source code of the Administration shows how the switch works: if it is off, bulk edit sends every status change with the header sw-skip-trigger-flow, and the flows for these changes do not run (Shopware source code). Whether that is desirable depends on what is attached to the triggers. A flow on “delivery changes to Shipped” can send a shipping email, generate a document, set a tag or assign another status (Shopware documentation). Switching flows off switches all of that off, not just the email. What else the Flow Builder can do is summarized in our article on the Shopware Flow Builder.

• Record triggers: which flows are attached to the triggers for the statuses set after sales events, such as payment “Paid”, delivery “Shipped”, order “Completed”?
• Read actions: do these flows send emails, generate documents, set tags or call an address outside the shop?
• Find duplicate paths: does a flow send the same information that the “Status emails” switch also sends? Then the customer receives two emails or two attachments.
• Set the order: if several flows use the same trigger, the priority determines which runs first (Shopware documentation).
• Note the decision: record for each pass whether status emails and flows were on or off. That saves searching later for why a customer did not receive a shipping email.

The volume of emails also belongs in the preparation. According to the developer documentation, Shopware sends emails synchronously by default; by configuration they can be sent via the message queue (Shopware developer documentation). If you trigger a large number of status emails in one pass after sales events, you should know beforehand which path is active in your shop and whether the workers run in the background. Our article on the message queue in production describes the setup. How the emails themselves should be structured is covered in the article on transactional emails and the order confirmation.

Documents in batches: invoice, delivery note, merged PDF

For invoice, cancellation invoice, delivery note and credit note, bulk edit can create documents for the whole selection, including several document types at once. If a document already exists, bulk edit does not create it again (Shopware documentation). An invoice requires a date, a comment is optional, and the corresponding number range increases automatically. The cancellation invoice uses the number of the last reference invoice, and the credit note is only created if the order contains a credit note item (Shopware documentation).

For printing, the form offers a download: the individual documents are provided in a merged PDF file, and new documents do not even have to be created for this; the most recent documents of each order are used (Shopware documentation). The merged PDF is a working file for the packing station. The documents themselves stay with the respective order; documents that were sent can also be seen by the customer in their account if the document template provides for it (Shopware documentation).

When documents are sent with the status email, there is one quirk: existing documents are attached automatically, but only the most recent one is used. If you create a document via bulk edit, that is exactly the one sent, regardless of whether another one already exists (Shopware documentation). The option “Skip already sent documents” prevents customers from receiving the same document twice. If you issue invoices as e-invoices in ZUGFeRD format, you will find the settings in the article ZUGFeRD directly from Shopware.

Limits: when an ERP update or the Admin API fits better

Bulk edit is a tool for people: someone filters, selects, decides on emails and flows and clicks Apply. That fits occasional batch steps. It fits less well when the same steps occur every day in large numbers, when the batch is well above 1,000 orders (Shopware documentation), or when each order needs its own piece of information that only another system knows, above all the tracking number.

If shipping is handled by an inventory system, the status update from there is usually the better route: the ERP knows the parcel, the tracking number and the dispatch time and can set the delivery status per order as soon as the parcel leaves the warehouse. Bulk edit then remains for exceptions. How such connections are built is shown on our pages on ERP and shop integrations, on connecting shipping providers and on the JTL-Wawi integration.

A run via the Admin API fits when orders are to be changed according to fixed rules that no inventory system provides, for example a correction after an error in a payment integration. For mass imports via the Sync API, the developer documentation describes the header sw-skip-trigger-flow, so that no flows and therefore no emails are triggered during the import (Shopware developer documentation). The Administration sets the same header when “Trigger flows” is off (Shopware source code). If you bring data from the ERP into the shop on a permanent basis, you will find a related case in the article on existing customers from the ERP.

Before Black Week: a checklist for fulfillment

After sales events there is no time left to get to know bulk edit calmly. Whatever can be clarified beforehand therefore belongs in the weeks before. The following list is designed so that it can be worked through in a test environment with copies of the shop settings, without using real customer data.

• Provide a test environment with the current state and without real customer data, as described in the article on Shopware staging without customer data.
• Record the flows on the triggers for payment, delivery and order and note their actions.
• Decide per status type: status emails on or off, trigger flows yes or no.
• Check email templates per sales channel; if no suitable template has been assigned to the sales channel yet, even the status change in the order details first asks for an assignment (Shopware documentation).
• Check the number ranges for invoice, delivery note and cancellation invoice before the first batch is created.
• Run a trial with a small selection and check emails, attachments, tags and documents on every order.
• Check the message queue and workers in production so that emails and documents do not get stuck in a backlog.
• Decide which system leads the status: inventory system or Administration. Maintaining it in both leads to duplicate emails.

Preparation also includes the question of what happens if something gets stuck on the sales days themselves. Load testing and an emergency plan are covered in the article on peak season, load testing and emergency planning. The checklist above adds the days after.

How we support the preparation

We set up Shopware shops for order peaks and support fulfillment afterward. For bulk edit, that mainly means reading the existing flows, recording decisions and testing the steps before they are needed.

Plan fulfillment before the orders arrive

Bulk edit takes a lot of clicking off the team after sales events, and it is part of the Shopware core. Its traps do not lie in the operation, but in what a status change triggers along the way: emails, flows, documents and number ranges. If you check these effects in a test environment before Black Week, plan for the limit of 1,000 orders per selection (Shopware documentation) and provide a status update from the inventory system for permanently large volumes, you work through the order backlog after the sales events in orderly passes.