- or
No existing idea results
- ~ No ideas found ~
1551 results found
-
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 -
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…
5 votes -
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 deletionCurrently 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…
2 votes -
Let B2B Employees changed their own password
It should be a standard functionality that a user can change their password.
This is currently not possible.
Please implement this.
2 votes -
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 -
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…
3 votes -
"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 -
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…
3 votes -
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…
1 vote -
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 -
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 -
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 -
Test
Test
1 vote -
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 -
payment method per customer
Default payment method should be available per customer so that we can use this information for
- customer account
- Reports
- order confirmation2 votes -
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”, oran 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…2 votes -
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 -
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 votesHi 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
-
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…
5 votes -
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 behaviorFor 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 orderThe 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 contextThis 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,…1 vote
- Don't see your idea?