- or
No existing idea results
- ~ No ideas found ~
1498 results found
-
Automatically remind users who abandon the shopping cart
Automatic reminder for shopping basket cancellations. Optionally with an incentive such as a discount code. Remind users who abandon their shopping basket (including guests) and optionally bring them back to the shop.
14 votes -
Improving admin management for product reviews
In order to work effectively with product reviews, improvements are needed in the admin management for product reviews.
Currently, managing reviews is not possible; there are no filters (e.g. product, stars, sales channel, language, approved, date) and after editing a review, you are taken straight back to the first page.6 votes -
Import/Export Cheapest price (last 30 days)
There should be a way to import/export the cheapest price (last 30 days).
There is a regulationPrice in the price field for this purpose, but it cannot currently be mapped.
6 votes -
Inheritable category and menu visibility in organizational units (B2B)
Currently, category and product visibility settings can only be explicitly configured per category within organizational units.
When a parent category is selected, the subcategories beneath it are not automatically included.
This leads to the following problems with extensive category structures (several hundred subcategories):
- very high manual maintenance effort
- increased susceptibility to errors
- poor maintainability when structural changes are made
- limited scalability in a B2B contextIn addition, the main menu must be controlled indirectly via individual assignments to the contained categories, as a blanket menu activation is not possible.
Target Image:
- Selecting a parent category should optionally include all subcategories automatically.
- Menu visibility should be configurable independently of individual assignments.
- Reduction of administrative effort for complex B2B structures.Specific Improvement Suggestions
A) Inheritable Category Visibility
Option 1: "Include Subcategories" CheckboxWhen selecting a category in the organizational unit:
☐ Automatically include subcategories
Behavior:
- Recursively activates all child categories.
- New subcategories are automatically included.
- Optionally overridable at the subcategory level.Technically feasible:
- Flag at the category assignment level
- Recursive query in the CategoryTreeLoader
- Lazy resolution in the Visibility ResolverB) Global Menu Sharing
New option in the organizational unit:☐ Show full main menu
Behavior:
- Menu structure is displayed
- Visibility of individual products remains adjustable
- Alternatively: Combination with category filter logicOptional:
- Visibility only structural (navigation visible, product access checked)Benefits
For Customers
- Massive time savings
- Significantly improved maintainability
- Scalability for large catalogs
- Fewer misconfigurationsFor Shopware
- Stronger B2B positioning
- Reduced support requests
- Less need for custom development
- Competitive advantage with enterprise customersCurrently, category and product visibility settings can only be explicitly configured per category within organizational units.
When a parent category is selected, the subcategories beneath it are not automatically included.
This leads to the following problems with extensive category structures (several hundred subcategories):
- very high manual maintenance effort
- increased susceptibility to errors
- poor maintainability when structural changes are made
- limited scalability in a B2B contextIn addition, the main menu must be controlled indirectly via individual assignments to the contained categories, as a blanket menu activation is not possible.
Target Image:
- Selecting a parent category…3 votes -
B2B Components: allow modification of Employee invite timeout
Currently there is a hard coded timeout of 2 hours when employees are invited into an organization in B2B Components. Shop owners and potentially customers should be able to modify this time to fit their needs.
4 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 -
B2B Components: Assign existing account to company account
Shop owners occasionally report that the unusual process of registering as a B2B employee leads to them signing up normally through the frontend which creates a bit of a mess.
It would be helpful if we provided the functionality to assign normal customers as employees to a B2B enabled company account as this would save effort for everyone involved.
Taking this idea further and to avoid unnecessary manual action for shop owners, we could implement this feature for the B2B account itself so THEY can invite existing (already registered) accounts to their company and integrate them into the B2B structure. Of course, for privacy reasons, they should not see if the mail already exists when inviting.
Shop owners occasionally report that the unusual process of registering as a B2B employee leads to them signing up normally through the frontend which creates a bit of a mess.
It would be helpful if we provided the functionality to assign normal customers as employees to a B2B enabled company account as this would save effort for everyone involved.
Taking this idea further and to avoid unnecessary manual action for shop owners, we could implement this feature for the B2B account itself so THEY can invite existing (already registered) accounts to their company and integrate them into the B2B structure.…
4 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 -
Product visibility: Only when customer has specific prices
There have been a few requests by B2B shop owners where the challenge is as follows:
Products should only be visible IF the observer/customer has specific prices for them. Basically, this means that no products are visible UNLESS the customer has a set price for it.
From the perspective of a former B2B procurement manager: This is a relatively common thing to see. I purchased tools for the manufacturing personnel, for example. I'd contact the potential suppliers once a year, we'd sit down, talk projected order volumes, figures and conditions.
After that was all negotiated, I'd get a price list for the various categories with individual prices, bonuses, conditions and so forth and the supplier would set it up on their end so that I could place orders online (if I wanted to) in their shop. Strictly speaking, I'd find all/most of the other items in their shop as well, but I would have preferred if I didn't - so my line of thinking aligns with the requests we got about this in Support, because I already negotiated every item which was relevant to the company I represented ahead of time - I don't need and don't want to see things I had no interest in and likely have no price list for either.
So - two birds with one stone:
1) The observer sees all the items they have a specific price for
2) The observer does not need to filter what is/was relevant to themThe implementation screams B2B Components. But I think the implementation is potentially simpler if done via Dynamic Access:
If we had a condition which checks whether or not the observer has custom prices of any sort (be it via customer group - this should be the first condition in my mind - extended prices OR customer specific prices, we'd have all the rest covered already.
There have been a few requests by B2B shop owners where the challenge is as follows:
Products should only be visible IF the observer/customer has specific prices for them. Basically, this means that no products are visible UNLESS the customer has a set price for it.
From the perspective of a former B2B procurement manager: This is a relatively common thing to see. I purchased tools for the manufacturing personnel, for example. I'd contact the potential suppliers once a year, we'd sit down, talk projected order volumes, figures and conditions.
After that was all negotiated, I'd get a price list…
3 votes -
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 -
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 -
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 -
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.
14 votes -
Admin orders: Add option to manually add deactivated products
A customer of ours suggested this feature;
It should be possible to have the option to add deactivated products to a manually placed order. Perhaps with a checkbox while we're adding the products or clearly mark the deactivated products in order to avoid mixing them up with active ones, in case product names are rather similar.
The specific usecase is this:
That merchant frequently places manual orders in their Admin for customers. Contrary to what one might assume (I did so as well), it is not a once-in-a-lifetime event that while you work on said manual order, another customer in the frontend already buys the stock away, leading to the product no longer being available. The shop owner reported THREE separate occasions where this happened and thus, understandably, now seeks a solution for these cases.
There are workarounds of course, but they all come with advantages and disadvantages and at least I was not able to think of any which is really failure proof. They all also require multiple steps to get them working (like manually adjusting stock amounts before the manual order and then after again) other than automating everything via API, which sort of defeats the point of Admin orders.
Assuming we tackle this problem, it should most definitely be a setting or option because if we show any and all products, even deactivated ones, as possible selection during the creation of manual orders, we'll probably introduce new problems for shops which only have products available once and never again afterwards. In these cases, the products likely end up disabled once they're sold out and they'd NOT want those to clutter the dropdown list when placing an Admin order.
A customer of ours suggested this feature;
It should be possible to have the option to add deactivated products to a manually placed order. Perhaps with a checkbox while we're adding the products or clearly mark the deactivated products in order to avoid mixing them up with active ones, in case product names are rather similar.
The specific usecase is this:
That merchant frequently places manual orders in their Admin for customers. Contrary to what one might assume (I did so as well), it is not a once-in-a-lifetime event that while you work on said manual order, another customer in…
2 votes -
E-invoice for cancellation invoice, too
Currrently only the invoice itself is abvailable for creating as a Zugferd format. The cancellation invoice should added as soon as possible, because this may lead to irriatations at accounting.
19 votes -
Role permissions for the image editor
Currently, it is not possible to enable or disable the image editor for users of a role.
Only the designated administrators have access to the image editor on Content > Image Editor.
2 votes -
PayPal: add option to disable Smart Payment Button for other payment methods
Currently, users can only disable the Smart Payment Buttons for the standard PayPal payment method, which replaces the (by default) yellow PayPal button with the standard button to conclude the checkout.
However that setting does not have effect on the other payment methods provided by PayPal, such as Apple Pay, Google Pay or even the Pay Later option by PayPal. Those still replace the default pay button with their own graphic.
It would be useful to be able to disable them as well to have more control over the shop design.
2 votes -
Configurable mapping of the buyer reference in e-invoices (ZUGFeRD / XRechnung)
In the current default behavior, the <BuyerReference> field in the generated e-invoice (ZUGFeRD / EN16931) is populated with the purchase order number.
However, for invoices to public sector clients (government agencies), the routing ID is generally required in the <BuyerReference> field. If the purchase order number is used instead, this can lead to:
- Validation errors in ERP/accounting systems (e.g., Lexware)
- Rejections by public sector clients
- Problems with input tax deduction
- Rejection by Peppol/XRechnung validators
Currently, there is no configuration option in the admin panel to adjust the BuyerReference mapping.
Problem:
- The<BuyerReference>parameter is not flexibly configurable by default.
- Merchants with government clients must provide the routing ID.
- - Currently, customization is only possible via:
- custom code
- event subscriber (ZugferdInvoiceGeneratedEvent)
- plugin customizations.
- This results in unnecessary implementation effort for a common scenario.Proposal
Introduce a configurable option in the document/e-invoice setup:Option A – Selection field in the Admin
In the section:
"Settings → Documents → E-Invoice"Configurable mapping field for BuyerReference (fe):
- Dropdown:
- Order number
- Customer number
- Custom field (from Customer)
- Custom field (from Order)
- Freely definable mapping (e.g., via Twig expression)In the current default behavior, the <BuyerReference> field in the generated e-invoice (ZUGFeRD / EN16931) is populated with the purchase order number.
However, for invoices to public sector clients (government agencies), the routing ID is generally required in the <BuyerReference> field. If the purchase order number is used instead, this can lead to:
- Validation errors in ERP/accounting systems (e.g., Lexware)
- Rejections by public sector clients
- Problems with input tax deduction
- Rejection by Peppol/XRechnung validators
Currently, there is no configuration option in the admin panel to adjust the BuyerReference mapping.
Problem:
- The<BuyerReference>parameter is not flexibly configurable by default.…2 votes -
Feature Request: Country-specific delivery times per shipping method
Currently, Shopware only allows one global delivery time per shipping method.
To accommodate different delivery times for each destination country, separate shipping methods must be created.
In more complex shipping setups, this leads to a very high number of shipping methods.
In this case:
- Approximately 130 standard shipping methods
- Approximately 100 express shipping methods
- Over 200 active shipping methods in total
This results in considerable administrative overhead regarding:
Maintenance and updates
Rule assignment
Quality assurance
Error potential
Overview in the admin panel
Especially with service providers like DHL and DHL Express, detailed, country-specific transit time tables exist that need to be updated regularly. Grouping by region (e.g., EU, USA, Asia) is not practical here, as transit times change dynamically and the grouping logic would have to be constantly adjusted.
Problem Statement
The current system architecture forces merchants to create multiple shipping methods simply to represent different delivery times for each country.There is no way to define delivery times, similar to shipping costs, differentiated by destination country.
Requested Feature
Extension of shipping methods to include country-specific delivery time logic, e.g.:- A matrix within a shipping method:
Country → Delivery Time
or alternatively
- Rule-based assignment of delivery times via the Rule Builder
The goal is to represent different delivery times for each country without having to create separate shipping methods.
Expected Added Value
- Significant reduction in the number of shipping methods
- Simplified maintenance when changing delivery times
- Improved clarity in the backend
- Reduced error susceptibility
- Better scalability for international shippingCurrently, Shopware only allows one global delivery time per shipping method.
To accommodate different delivery times for each destination country, separate shipping methods must be created.
In more complex shipping setups, this leads to a very high number of shipping methods.
In this case:
- Approximately 130 standard shipping methods
- Approximately 100 express shipping methods
- Over 200 active shipping methods in total
This results in considerable administrative overhead regarding:
Maintenance and updates
Rule assignment
Quality assurance
Error potential
Overview in the admin panel
Especially with service providers like DHL and DHL Express, detailed, country-specific transit time tables exist that need to…
2 votes
- Don't see your idea?