- or
No existing idea results
- ~ No ideas found ~
385 results found
-
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 votesGathering Feedback
We’re gathering feedback on this idea to better understand the need, use cases, and potential impact. At this stage, no implementation decision has been made.
Please continue to vote and share details about how this would help you. Your feedback will support our evaluation and help us decide whether to move the idea forward.
-
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 votesGathering Feedback
We’re gathering feedback on this idea to better understand the need, use cases, and potential impact. At this stage, no implementation decision has been made.
Please continue to vote and share details about how this would help you. Your feedback will support our evaluation and help us decide whether to move the idea forward.
-
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 votesGathering Feedback
We’re gathering feedback on this idea to better understand the need, use cases, and potential impact. At this stage, no implementation decision has been made.
Please continue to vote and share details about how this would help you. Your feedback will support our evaluation and help us decide whether to move the idea forward.
-
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 -
Feedback regarding voucher/promotion response in the shopping cart
Topic: Missing User Feedback for Unactivated Coupon Promotions
Description:
When a customer enters a coupon code linked to a promotion during checkout, it is technically validated.If the promotion cannot be activated due to the current contents of the shopping cart (e.g., due to product category or discount restrictions), the customer receives no feedback on the front end.
From the customer's perspective, nothing happens – even though the code would be valid.
Current Behavior (Default):
- Coupon is checked in the background.
- No error message or information is displayed if conditions are not met.
- The customer does not know whether the code is invalid or if there are simply no matching items in the shopping cart at the moment.Expected Behavior / Improvement Suggestion:
- Display of feedback such as:
"The coupon has been accepted, but there are currently no matching items in the shopping cart."
- Alternatively: A generic message stating that the coupon will be activated as soon as matching items are added to the shopping cart.Rationale:
- Increases transparency and customer trust.
- Avoids frustration caused by seemingly "non-functional" coupons.
- Improves user experience without impacting existing promotion logic.Suggested implementation:
- Add an informational message to the frontend (e.g., in the sw-promotion-code-form or via AddCodeError/AddCodeSuccess handling).
- Alternatively: A backend event hook that checks promotions and provides a flag or message object.Topic: Missing User Feedback for Unactivated Coupon Promotions
Description:
When a customer enters a coupon code linked to a promotion during checkout, it is technically validated.If the promotion cannot be activated due to the current contents of the shopping cart (e.g., due to product category or discount restrictions), the customer receives no feedback on the front end.
From the customer's perspective, nothing happens – even though the code would be valid.
Current Behavior (Default):
- Coupon is checked in the background.
- No error message or information is displayed if conditions are not met.
- The customer does not…6 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 votesGathering Feedback
We’re gathering feedback on this idea to better understand the need, use cases, and potential impact. At this stage, no implementation decision has been made.
Please continue to vote and share details about how this would help you. Your feedback will support our evaluation and help us decide whether to move the idea forward.
-
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 -
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 voteGathering Feedback
We’re gathering feedback on this idea to better understand the need, use cases, and potential impact. At this stage, no implementation decision has been made.
Please continue to vote and share details about how this would help you. Your feedback will support our evaluation and help us decide whether to move the idea forward.
-
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 votesGathering Feedback
We’re gathering feedback on this idea to better understand the need, use cases, and potential impact. At this stage, no implementation decision has been made.
Please continue to vote and share details about how this would help you. Your feedback will support our evaluation and help us decide whether to move the idea forward.
-
Enable Variant Changes Directly in the Shopping Basket and Checkout
Currently, when customers want to change a variant of a product already added to the shopping basket — for example, choosing a different size or color — they are required to leave the basket or checkout and navigate back to the product detail page. This process interrupts the purchasing flow and increases the likelihood of order cancellations or customer frustration.
With this enhancement, customers should be able to easily modify product variants directly from the basket or checkout interface.
Functional Proposal:
Add a variant selector for each product line item in the shopping basket and checkout.
When a customer changes a variant, the system automatically updates the line item’s price, stock information, and product image accordingly.
Currently, when customers want to change a variant of a product already added to the shopping basket — for example, choosing a different size or color — they are required to leave the basket or checkout and navigate back to the product detail page. This process interrupts the purchasing flow and increases the likelihood of order cancellations or customer frustration.
With this enhancement, customers should be able to easily modify product variants directly from the basket or checkout interface.
Functional Proposal:
Add a variant selector for each product line item in the shopping basket and checkout.
When a customer changes…
6 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 votesGathering Feedback
We’re gathering feedback on this idea to better understand the need, use cases, and potential impact. At this stage, no implementation decision has been made.
Please continue to vote and share details about how this would help you. Your feedback will support our evaluation and help us decide whether to move the idea forward.
-
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 voteGathering Feedback
We’re gathering feedback on this idea to better understand the need, use cases, and potential impact. At this stage, no implementation decision has been made.
Please continue to vote and share details about how this would help you. Your feedback will support our evaluation and help us decide whether to move the idea forward.
-
B2B Components: add CSV bulk import of Employees and Addresses
Some customers may receive the request from business partners to create a lot of employee account with different addresses (see for example support case #SWAG-322222).
Currently each employee and address would need to be added by hand or via the API. Bulk importing as a CSV would make this a lot easier.
3 votes -
AI: Productstreams / Crossselling
Little has happened since the introduction of AI.
The use of AI to generate customer-specific product streams for cross-selling would be indispensable and a major step forward. For example, based on order history. This is very important for the customer.
Cross-selling is currently very rigid. AI could be used to analyze the customer's order and then make specific suggestions. This would be a huge step and benefit for customers and a game changer.
15 votesGathering Feedback
We’re gathering feedback on this idea to better understand the need, use cases, and potential impact. At this stage, no implementation decision has been made.
Please continue to vote and share details about how this would help you. Your feedback will support our evaluation and help us decide whether to move the idea forward.
-
Add more granular permissions for PayPal
Currently, every admin user with the permission to edit an order (order.editor) can issue refunds of PayPal payments. It would be very helpful to add more granular permissions so that employees can modify orders but cannot issue refunds.
4 votes -
Quick check for plugin and dependency updates compatible with current Shopware version
Right now, there’s no quick way to see which plugin or dependency updates are actually compatible with the installed Shopware version.
composer outdated shows all new versions, ignoring compatibility.
The Admin popup just says “updates available” without details.
It would be very helpful to have a CLI command and/or an Admin view that lists only installable updates based on the current Shopware version.
7 votes
- Don't see your idea?