1564 results found

1. QOL User Experience Settings

   I will take the example of warehouses but it's a general QOL functionality that could be handy. I used to work for Odoo and I'm suggesting some nice general UI improvements that would reduce clicks and manual work.

   1) When you click on WH1 you open it, you don't need to click on the 3 dots
   2) Once you are in WH2 on the right there would be an arrow to go to the previous or next record (in this case warehouses)
   3) In the Warehouse Group when you start typing you could create a new group directly on the go by typing the name and click on create new
   4) You don't need to manually click Save every time. It would save automatically for you if you go back, to the next record or to another menu item.
   5) On the product page in the backend it would be nice to have a button to go directly to the frontend page to see how it looks there.

   I will take the example of warehouses but it's a general QOL functionality that could be handy. I used to work for Odoo and I'm suggesting some nice general UI improvements that would reduce clicks and manual work.

   1) When you click on WH1 you open it, you don't need to click on the 3 dots
   2) Once you are in WH2 on the right there would be an arrow to go to the previous or next record (in this case warehouses)
   3) In the Warehouse Group when you start typing you could create a new group directly on the… more

   •  

   •  

   1 vote

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  User Experience  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

2. Use Categories en Gender form category tree in filters

   If you organize your categories by gender in Shopware, you have a clear gender-specific funnel with clear and structured navigation. Why aren't these also used in the filters, or why do you have the option to do so?

   Applying all filters via attributes doesn't work well. Especially not on the brands page, where you don't have good SEO-friendly pages based on brand/category. If we enable categories and genders in the filters, we only see the male gender for unisex products when filtering for women, whereas you don't want to see men at all when you are in the women's funnel. And if we enable categories, we see duplicate categories for all genders on the brands page (deduplication is not possible). If you then click on "sneaker," for example, you don't know which gender you are going to.

   For complex websites, let users choose for themselves what they want to link to the attributes (filters). The standard category tree seems best to me in that case.

   Also, make categories, brands, and quicklinks dynamic. So if there are no active products from the brand or category, automatically disable them for the front-end (including the quicklink).

   The brand page could also be much better in the default settings: navigate by brand by gender, meta titles and meta descriptions, search field in navigation.

   If you organize your categories by gender in Shopware, you have a clear gender-specific funnel with clear and structured navigation. Why aren't these also used in the filters, or why do you have the option to do so?

   Applying all filters via attributes doesn't work well. Especially not on the brands page, where you don't have good SEO-friendly pages based on brand/category. If we enable categories and genders in the filters, we only see the male gender for unisex products when filtering for women, whereas you don't want to see men at all when you are in the… more

   1 vote

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Products, Prices & Properties  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

3. Revocation request trigger - Setting an automatic revocation tag at the relevant orders

   When the revocation request trigger is used in the flow builder, it is only possible to activate the "send e-mails" or "stop the flow" process.

   It would be great if the revocation request trigger would also allow to automatically set a revocation tag at the relevant order. This would help to easily mark the orders, which have been revoked.

   1 vote

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Orders & Customers  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

4. Multi-user support for customer service representatives – login as any company employee in a B2B environment

   In B2B transactions, customer service representatives regularly handle and process orders on behalf of customers, especially for telephone orders or orders requiring extensive consultation.

   Currently, they log in to the backend with administrator rights and then use the "Log in as customer" function in the frontend to place orders directly in the shop or to assist customers with their use.

   However, this approach currently only works for the primary user of a company account.

   In cases where a customer uses multiple employee accounts within a company structure, it is not possible to log in as another employee of that company to, for example, place an order on behalf of a specific employee or to review their purchase approvals.

   Goal / Benefit

   To enable customer service representatives or administrators to log in to the shop as any employee of a company account.

   This allows support staff to authentically process telephone orders, approval processes, or reorders on behalf of the correct employee.

   Improved traceability (correct customer, correct rights and approvals) and simplification of customer support in the B2B environment.

   In B2B transactions, customer service representatives regularly handle and process orders on behalf of customers, especially for telephone orders or orders requiring extensive consultation.

   Currently, they log in to the backend with administrator rights and then use the "Log in as customer" function in the frontend to place orders directly in the shop or to assist customers with their use.

   However, this approach currently only works for the primary user of a company account.

   In cases where a customer uses multiple employee accounts within a company structure, it is not possible to log in as another employee of that company… more

   5 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   PLANNED  ·  1 comment  ·  B2B  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

5. Allow B2B employee deletion when pending orders exist - GDPR compliance

   Currently deleting a B2B employee who has pending orders fails with a raw FK constraint error (SQLSTATE 23000). The only workaround suggested is cascade-deleting the orders, which is unacceptable.

   Real-world scenario: An employee leaves the company. The organization is legally required under GDPR (right to erasure) to remove that person's personal data. However, pending orders are financial records of the organization, not the employee's personal data, and must be preserved.

   The fix does not require decoupling orders from customers. It only requires allowing employee_id on pending orders to be nullified (SET NULL) or reassigned to another employee before deletion. The order record stays intact, only the link to the former employee is removed.

   Impact: Every B2B merchant with employee turnover faces this. In the EU, GDPR compliance is not optional - merchants cannot tell regulators "Shopware doesn't support it."

   Suggested solution:
   1. Change FK fk.pendingorder.employeeid to ON DELETE SET NULL
   2. Provide a way to reassign pending orders to another employee before deletion

   Currently deleting a B2B employee who has pending orders fails with a raw FK constraint error (SQLSTATE 23000). The only workaround suggested is cascade-deleting the orders, which is unacceptable.

   Real-world scenario: An employee leaves the company. The organization is legally required under GDPR (right to erasure) to remove that person's personal data. However, pending orders are financial records of the organization, not the employee's personal data, and must be preserved.

   The fix does not require decoupling orders from customers. It only requires allowing employee_id on pending orders to be nullified (SET NULL) or reassigned to another employee before deletion. The… more

   •  

   2 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  B2B  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

6. Nexus (Open Beta)

   Nexus is an event orchestration platform that allows you to develop critical business workflows with 3rd party systems (ERP, CRM, PIM, etc).

   2 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Automation  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

7. Advanced Product Catalogues - Assign Category & Product Visibility Via Pre-Defined "Template"

   ENG: Use case: As a shop operator with many categories and products, I don't want to have to individually determine which categories and products a unit should have access to when creating organizational units. Instead, it should be possible to create templates—which may only be usable and visible at the admin level—that can be used to define viewing permissions accordingly. If I then need to create several organizational units, I could simply—where possible—quickly define the permissions using the template without having to manually define the same permissions again and again for each additional organization.

   DE: Use-Case: Als Shopbetreiber mit vielen Kategorien und Produkten möchte ich bei der Erstellung einer Organisationseinheiten nicht immer individuell bestimmen müssen, auf welche Kategorien und Produkte ein Einheit Zugriff haben soll. Vielmehr muss es die Möglichkeit gebene, das - ggf. nur auf Adminebene nutzbar und sichtbar - Templates erstellt werden können, über die Sichtberechtigungen entsprechend definiert werden können. Sofern ich dann mehrere Organisationsienheiten erstellen muss, könnte ich dann einfach - wo möglich - die Sichtberechtigungen schnell über das Template festlegen lassen ohne dieselben Berechtigungen abermals für jede weitere Organisatzion manuell festlegen zu müssen.

   ENG: Use case: As a shop operator with many categories and products, I don't want to have to individually determine which categories and products a unit should have access to when creating organizational units. Instead, it should be possible to create templates—which may only be usable and visible at the admin level—that can be used to define viewing permissions accordingly. If I then need to create several organizational units, I could simply—where possible—quickly define the permissions using the template without having to manually define the same permissions again and again for each additional organization.

   DE: Use-Case: Als Shopbetreiber mit vielen… more

   3 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  B2B  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

8. "epub" should be a standard upload file for digital products, as this is the standard file for e-books

   As nearly all ebooks are sold as PDF- or epub-files (most ebooks) , "epub" should be integrated into the list of files, that can be uploaded (esp. if you create a digital product).

   2 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Products, Prices & Properties  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

9. Rule-based hiding of Buy button

   In Shopware 6, the visibility of products can already be controlled via rules by using the dynamic access extension (up to a certain point, as the stock is not being validated). However, there currently is no native way to hide or disable the “Buy / Add to cart” button based on rules, especially when combining customer groups with product stock conditions.

   In B2B and hybrid B2C/B2B scenarios, it is common that products with stock = 0 (with closeout enabled) should still be orderable for specific customer groups, while the buy button should be hidden or disabled for all other customer groups. Moreover it should be possible to set "closeout" on sales channel level.

   In Shopware 6, the visibility of products can already be controlled via rules by using the dynamic access extension (up to a certain point, as the stock is not being validated). However, there currently is no native way to hide or disable the “Buy / Add to cart” button based on rules, especially when combining customer groups with product stock conditions.

   In B2B and hybrid B2C/B2B scenarios, it is common that products with stock = 0 (with closeout enabled) should still be orderable for specific customer groups, while the buy button should be hidden or disabled for all other customer… more

   3 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  System & Settings  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

10. Agentic Commerce - Beta Release

    The Agentic Commerce plugin enables merchants to distribute products through OpenAI and Google product feeds while supporting emerging standards such as UCP (Universal Commerce Protocol). It provides a dedicated sales channel for AI-driven commerce and helps merchants prepare for the next generation of product discovery and purchasing experiences.

    -> Help Shape the Future of Agentic Commerce

    AI-powered commerce is evolving rapidly, and we're continuously expanding the capabilities of Agentic Commerce.

    Do you have ideas, feature requests, or suggestions for improvement? We'd love to hear your feedback. Share your thoughts on UserVoice and help us shape the future of AI-powered commerce in Shopware.

    The Agentic Commerce plugin enables merchants to distribute products through OpenAI and Google product feeds while supporting emerging standards such as UCP (Universal Commerce Protocol). It provides a dedicated sales channel for AI-driven commerce and helps merchants prepare for the next generation of product discovery and purchasing experiences.

    -> Help Shape the Future of Agentic Commerce

    AI-powered commerce is evolving rapidly, and we're continuously expanding the capabilities of Agentic Commerce.

    Do you have ideas, feature requests, or suggestions for improvement? We'd love to hear your feedback. Share your thoughts on UserVoice and help us shape the future of AI-powered commerce… more

    1 vote

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    STARTED  ·  0 comments  ·  Sales Channels  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

11. Filter visibility by selected sales channels

    For products, there is an option to set visibility for selected sales channels.
    
    This setting determines whether a product appears in search results or in the product listing.
    
    However, to see what is set for a product here, you have to open the product page and then click the settings button again.

    It would be nice to have an option right here in the product overview to filter by visibility settings.

    2 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Products, Prices & Properties  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

12. Allow for CMS elements to be hidden on category pages when product listing page is not the first page

    When a category layout contains some text or images together with the product listing element, that text or element may be indexed by search engines multiple times for each page of the listing, leading to duplicate indexing and results.

    It would be helpful if certain elements could be hidden once the customer or the indexing bot navigates through the listing pages, or a URL contains the ?p= parameter. This would prevent redundant indexing.

    2 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Content management  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

13. The scrollbar in the category tree needs to be more user-friendly.

    If the shop has a complex category structure, navigating the categories in the admin area can quickly become very confusing. It often requires clicking and using the scroll bar, which is located at the very end of the category tree. This means users have to repeatedly scroll to the end of the tree, which is very time-consuming and needs to be simplified.

    3 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  System & Settings  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

14. Landingpages Canonical-Link setzen

    Landingpages sollten auch einen (wählbaren) Canonical-Link erhalten. So wie Kategorieseiten und Produktseiten.

    Landing pages should also have a selectable canonical link, just like category pages and product pages.

    1 vote

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  SEO  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

15. payment method per customer

    Default payment method should be available per customer so that we can use this information for
    - customer account
    - Reports
    - order confirmation

    2 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Orders & Customers  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

16. Optional inclusion of “free shipping” products in cart value for threshold rules

    Use case

    We configure shipping so that standard shipping is free from a minimum order value (e.g. 50 €), using price-based shipping costs on the shipping method.

    Current behaviour

    Products marked “free shipping” are excluded from the value used for all shipping price calculations (via getWithoutDeliveryFree() in DeliveryCalculator::matches()). That means:

    If the cart mixes free-shipping and regular products, only the non–free-shipping lines count toward the threshold.
    Example: total cart 60 €, but only 40 € from non–free-shipping lines → the customer is below the 50 € free-shipping threshold and pays shipping, even though the visible cart total is above 50 €.

    Expected / desired behaviour
    For price-based rules (minimum order value / free shipping from X €), we need the full cart value (or a configurable choice) to determine the tier, not only the sum excluding free-shipping products.
    Products marked “free shipping” should still ship without their own fee when they are the only items, but when combined with other products, they should count toward the threshold so behaviour matches merchant and customer expectations.

    Suggestion

    Please consider one of:
    A configuration option on the shipping method or globally: “include free-shipping products in cart value for price-based shipping rules”, or

    an extension point (e.g. protected method, strategy, or event) so projects can implement this without forking DeliveryCalculator.

    Use case

    We configure shipping so that standard shipping is free from a minimum order value (e.g. 50 €), using price-based shipping costs on the shipping method.

    Current behaviour

    Products marked “free shipping” are excluded from the value used for all shipping price calculations (via getWithoutDeliveryFree() in DeliveryCalculator::matches()). That means:

    If the cart mixes free-shipping and regular products, only the non–free-shipping lines count toward the threshold.
    Example: total cart 60 €, but only 40 € from non–free-shipping lines → the customer is below the 50 € free-shipping threshold and pays shipping, even though the visible cart total is above 50… more

    2 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Checkout  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

17. Increase value for "items per page" on customer > addresses (make it configurable)

    Increase value for "items per page" on customer > addresses:

    • Add values "250" and "500"
    • Make default value for "items per Page" configurable so it can be set to <>25
    2 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  System & Settings  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

18. Low Visibility of Required Confirmation Checkbox in Checkout Process

    Hello,

    We are currently using the “Outdoor” theme. Our products offer several customizable options, and before customers can proceed to checkout, they must confirm that their selected product configuration is correct by checking the confirmation box.

    However, the checkbox is currently barely visible, which may cause customers to overlook it. As a result, some customers might abandon the checkout process because they do not notice that confirmation is required before proceeding to payment.

    We would appreciate it if the visibility of the checkbox could be improved to make the checkout process clearer and more user-friendly.

    Thank you !

    •  

    0 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Checkout  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating
    DECLINED  ·  AdminSandor Akszenovics (Admin, shopware AG) responded

    Hi Michael,

    
    

    thanks for reaching out and for the detailed feedback!

    We advice you to reach out to the "Outdoor" theme vendor (Themeware https://store.shopware.com/en/tcinn85265076285m/themeware-outdoor-pro-sales-increasing-and-customizable.html ) for support in this case.

    
    

    Kind regards,

    Sandor

    
    

19. Payment method change after order receipt with new payment method

    Currently, when changing the payment method of an existing order (/account/order/edit-payment), the rule engine is not re-executed.

    Instead, Shopware continues to use the payment methods that were available at the time the original order was placed.

    This results in the following scenarios not being handled correctly:
    - Payment methods become valid for the customer retroactively (e.g., based on tags, customer groups, or rules) → but do not appear in the selection.
    - Rules change retroactively (e.g., "Always valid" is added) → no update occurs.
    - Changes to customer data, addresses, or order items are not reflected.

    This means that customers cannot select an updated payment method, even if they meet the requirements after placing the order.

    The payment method cannot currently be changed in the admin panel either.

    When changing the payment method for an existing order, the payment methods should be determined dynamically based on current data and rules – not based on historical data.

    The customer should therefore always see all currently valid payment methods.

    Currently, when changing the payment method of an existing order (/account/order/edit-payment), the rule engine is not re-executed.

    Instead, Shopware continues to use the payment methods that were available at the time the original order was placed.

    This results in the following scenarios not being handled correctly:
    - Payment methods become valid for the customer retroactively (e.g., based on tags, customer groups, or rules) → but do not appear in the selection.
    - Rules change retroactively (e.g., "Always valid" is added) → no update occurs.
    - Changes to customer data, addresses, or order items are not reflected.

    This means that customers… more

    5 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Orders & Customers  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

20. Support immutable promotion versions behind stable promotion codes

    Currently, Shopware locks certain promotion discount settings after a promotion has been used in an order. For example, the discount amount can no longer be changed once the promotion was applied at least once.
    From a data integrity perspective, this is understandable: changing the discount definition after it has already been used could affect order recalculation, order editing, tax distribution, or historical consistency.
    However, from a merchant perspective this creates a practical limitation. A commonly used promotion code such as WELCOME cannot easily be reused with a changed discount configuration. The merchant either has to create a new visible code, or the existing promotion becomes effectively frozen.

    Suggested improvement
    Shopware could support immutable promotion versions behind a stable public promotion code.
    The customer-facing code would remain unchanged, for example:

    Internally, Shopware would resolve this code to a concrete promotion version.

    Example:

    Code: WELCOME
    Version 1:

    internal promotion/version ID: abc123
    valid from: 2026-01-01
    valid until: 2026-03-31
    discount: 10%
    used for existing orders / historical order edits only
    Version 2:
    internal promotion/version ID: def456
    valid from: 2026-04-01
    valid until: open
    discount: 15%
    used for new carts and new orders
    Expected behavior

    For new carts and new orders, the entered code WELCOME should resolve to the currently active promotion version.

    For existing orders, order edits, recalculations, or similar historical operations, Shopware should continue to use the originally applied promotion version.

    In other words:

    New checkout:
    WELCOME → latest active promotion version
    Existing order edit:
    use the promotion version that was originally applied to this order

    The old version should not remain generally usable just because it was valid in the past. It should only be used where there is already a concrete historical reference, for example on an existing order that originally used that version.

    Why this would help

    This would preserve historical calculation integrity while allowing merchants to keep stable, recognizable promotion codes.

    It would also avoid forcing merchants to create new customer-facing codes every time they want to adjust a promotion. Common codes such as WELCOME, SUMMER, or BLACKWEEK could stay the same while their internal discount definition is versioned safely.

    Possible implementation approach

    Instead of modifying a promotion discount definition after first usage, Shopware could create a new immutable promotion version.

    The admin UI could offer an action such as:

    Create new version of this promotion

    This new version would inherit the existing configuration, allow changes to the discount settings, and become the active version for future carts.

    Existing orders would continue to reference the previous version.

    Benefits

    Keeps historical order data stable
    Avoids recalculation inconsistencies
    Allows merchants to reuse established promotion codes
    Improves usability in the Administration
    Provides a cleaner alternative to permanently locked discount fields
    Makes promotion changes explicit and traceable
    Additional context

    This is not meant as a request to allow direct editing of already-used discount definitions. The goal is to keep those definitions immutable, but introduce a versioning layer so that the same public promotion code can safely point to a newer internal promotion version for future orders.

    Currently, Shopware locks certain promotion discount settings after a promotion has been used in an order. For example, the discount amount can no longer be changed once the promotion was applied at least once.
    From a data integrity perspective, this is understandable: changing the discount definition after it has already been used could affect order recalculation, order editing, tax distribution, or historical consistency.
    However, from a merchant perspective this creates a practical limitation. A commonly used promotion code such as WELCOME cannot easily be reused with a changed discount configuration. The merchant either has to create a new visible code,… more

    1 vote

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Marketing & Promotions  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating