- or
354 results found
-
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.
4 votes -
Standardize shortName for Categories to ensure App and Headless stability
Shopware provides a shortName for SalesChannels to enable environment-agnostic identification, yet this primitive is missing for Categories. This inconsistency forces App developers and Headless integrators to rely on volatile SEO URLs or environment-specific UUIDs to identify "Page Types" (e.g., Home, Support, Landing Page).
By extending shortName to the Category entity, Shopware would provide a stable, indexed, and semantic developer contract. This eliminates the need for redundant repository searches or brittle Custom Field lookups, which currently penalize performance and complicate CI/CD pipelines. Standardizing this across core entities ensures that external systems can resolve both "Shop Context" and "Location Context" using the same native logic, drastically simplifying the integration of marketing, tracking, and CMS-driven Apps.
Shopware provides a shortName for SalesChannels to enable environment-agnostic identification, yet this primitive is missing for Categories. This inconsistency forces App developers and Headless integrators to rely on volatile SEO URLs or environment-specific UUIDs to identify "Page Types" (e.g., Home, Support, Landing Page).
By extending shortName to the Category entity, Shopware would provide a stable, indexed, and semantic developer contract. This eliminates the need for redundant repository searches or brittle Custom Field lookups, which currently penalize performance and complicate CI/CD pipelines. Standardizing this across core entities ensures that external systems can resolve both "Shop Context" and "Location Context" using…
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.
-
JSON-basierte Konfigurationen importieren, exportieren und versionieren
EN:
I just read this interesting LinkedIn post about n8n workflows:
https://www.linkedin.com/posts/fs-net_n8n-workflows-baue-ich-gr%C3%B6%C3%9Ftenteils-nicht-ugcPost-7470006922243391488-e6gCThe core idea: workflows should not only be edited in the UI, but also managed as structured JSON files that can be versioned, reviewed, and deployed automatically.
A similar approach would be extremely valuable for Shopware Nexus:
Configurations, mappings, flows, and middleware logic could be exported and imported as JSON. This would make them cleanly versionable in Git, reviewable via pull requests, and deployable between test and production environments.
The AI aspect would be especially exciting: if Nexus configurations existed as well-documented JSON structures, AI coding agents could work directly with them. New integrations, mapping changes, or validations could be generated via prompt instead of configuring everything manually in the UI.
Important mechanisms would include placeholders for environment-specific values, separate credential references, validation scripts, and drift checks between the UI and the repository.
The UI would still remain important for overview, debugging, and manual adjustments. But JSON as an additional technical representation would open up Nexus much more strongly to professional development processes, CI/CD, and AI-assisted configuration.
Ich habe gerade diesen spannenden LinkedIn-Beitrag zu n8n-Workflows gelesen:
https://www.linkedin.com/posts/fs-net_n8n-workflows-baue-ich-gr%C3%B6%C3%9Ftenteils-nicht-ugcPost-7470006922243391488-e6gCDer zentrale Gedanke: Workflows nicht nur im UI bearbeiten, sondern als strukturierte JSON-Dateien verwalten, versionieren, reviewen und automatisiert deployen.
Für Shopware Nexus wäre ein ähnlicher Ansatz extrem wertvoll:
Konfigurationen, Mappings, Flows und Middleware-Logik könnten als JSON exportiert und importiert werden. Damit wären sie sauber in Git versionierbar, per Pull Request reviewbar und zwischen Test- und Produktivumgebungen deploybar.
Besonders spannend wäre außerdem der KI-Aspekt: Wenn Nexus-Konfigurationen als gut dokumentierte JSON-Strukturen vorliegen, könnten AI Coding Agents direkt darauf arbeiten. Man könnte per Prompt neue Integrationen, Mapping-Änderungen oder Validierungen erzeugen lassen, statt alles manuell im UI zu konfigurieren.
Wichtig wären dabei Mechanismen wie Platzhalter für umgebungsspezifische Werte, getrennte Credential-Referenzen, Validierungsskripte und Drift-Checks zwischen UI und Repository.
Das UI bleibt weiterhin wichtig für Übersicht, Debugging und manuelle Anpassungen. Aber JSON als zusätzliche technische Repräsentation würde Nexus deutlich besser für professionelle Entwicklungsprozesse, CI/CD und AI-gestützte Konfiguration öffnen.
EN:
I just read this interesting LinkedIn post about n8n workflows:
https://www.linkedin.com/posts/fs-net_n8n-workflows-baue-ich-gr%C3%B6%C3%9Ftenteils-nicht-ugcPost-7470006922243391488-e6gCThe core idea: workflows should not only be edited in the UI, but also managed as structured JSON files that can be versioned, reviewed, and deployed automatically.
A similar approach would be extremely valuable for Shopware Nexus:
Configurations, mappings, flows, and middleware logic could be exported and imported as JSON. This would make them cleanly versionable in Git, reviewable via pull requests, and deployable between test and production environments.
The AI aspect would be especially exciting: if Nexus configurations existed as well-documented JSON structures, AI coding agents could…
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.
-
Custom Delivery Statuses for Advanced Logistics Processes
Many merchants require delivery statuses that go beyond the standard statuses provided by Shopware, especially when operating complex warehouse and fulfillment processes with ERP/WMS integrations and B2B workflows.
The current set of delivery statuses is often insufficient to accurately reflect real operational states within the fulfillment process.
Examples of commonly needed custom delivery statuses include:
- On Hold
- Partially Pickable
- Waiting for Stock
- B2B Special Process
A valuable enhancement would be the ability to create and manage custom delivery statuses within the administration and use them throughout the order and fulfillment workflow.
This would enable merchants to better represent their internal logistics processes, improve transparency for customer service teams, and support more complex B2B and warehouse management scenarios without relying on workarounds or custom developments.
Many merchants require delivery statuses that go beyond the standard statuses provided by Shopware, especially when operating complex warehouse and fulfillment processes with ERP/WMS integrations and B2B workflows.
The current set of delivery statuses is often insufficient to accurately reflect real operational states within the fulfillment process.
Examples of commonly needed custom delivery statuses include:
- On Hold
- Partially Pickable
- Waiting for Stock
- B2B Special Process
A valuable enhancement would be the ability to create and manage custom delivery statuses within the administration and use them throughout the order and fulfillment workflow.
This would enable merchants to better represent their internal…
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.
-
ZIP code validation only takes effect once all other mandatory fields have been filled in during checkout.
While testing the checkout process, I noticed inconsistent behavior when validating the postal code.
Steps to reproduce:
Go to checkout.
Select country.
Enter an invalid value in the “Postal code” field (e.g., asdasd or asd123).
Leave at least one other required field blank.
Click “Continue.”
Result:
All required fields are marked as incorrect except for country and zip code.
The zip code is not displayed as invalid in this state.Further behavior:
As soon as the previously missing required field is filled in, the zip code validation takes effect retrospectively and the field is then marked as incorrect.Expected behavior:
The ZIP code should be validated immediately as soon as an invalid format is entered, regardless of the status of other required fields or alternatively, a uniform validation behavior should be applied to all required fields.Note:
Even though this case is likely to occur rarely, the behavior appears inconsistent to users and could lead to confusion.While testing the checkout process, I noticed inconsistent behavior when validating the postal code.
Steps to reproduce:
Go to checkout.
Select country.
Enter an invalid value in the “Postal code” field (e.g., asdasd or asd123).
Leave at least one other required field blank.
Click “Continue.”
Result:
All required fields are marked as incorrect except for country and zip code.
The zip code is not displayed as invalid in this state.Further behavior:
As soon as the previously missing required field is filled in, the zip code validation takes effect retrospectively and the field is then marked as incorrect.Expected behavior:…
4 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 -
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.
3 votes -
import / export individual coupon codes
It should be possible to import / export individual coupon codes for easy use in other third-party systems.
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.
-
Orderdetails should show the B2B employee mail address
If an order is initiated by a B2B employee, we display the employee's first and last name in the order details (admin), but the email address associated with that employee is not listed. Instead, the email address of the “main customer” is displayed by default.
We already had a feature request about this topic BUT in regards to the old B2B Suite here:
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.
-
Scraper
In Odoo they have a website scraper which allows you to put the url of an existing website/ecommerce and it will create the shop and the website with the theme and snippets/images and so on from the existing website. Especially for demo purposes this could be very powerful to give a product showcase with a very personalized and themed style of the prospect's branding.
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.
-
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…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.
-
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 women's funnel.…
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.
-
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 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.
-
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 -
Individuelle Steuersätze für Kundengruppen
Individuelle Steuersätze für Kundengruppen
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.
-
"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 -
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.
- Don't see your idea?