- or
No existing idea results
- ~ No ideas found ~
1527 results found
-
Validation of individual voucher codes
At present, there is no check to verify whether individual promo codes generated according to a custom pattern result in a valid code.
Although the result is displayed in a preview, if you enter a pattern containing a hyphen (‘-’), no valid code can be generated, as hyphens appear to be reserved for the PRE and SUFFIX fields.
Example: %s%s%d%d-%d%d-%d%d%d%s
This would produce the following result: UP21-%d%d-%d%d%d%s
The pattern following the hyphen is used as the code. Although this should be noticeable during creation due to the preview, validation would nevertheless be more sensible and is requested.
1 vote -
Subscriptions available in Evolve
Include Shopware Subscriptions already for lower tier plan(s) - at least Evolve.
2 votes -
Improvement Proposal: Enhance Mail & Flow Logic for B2B Employee Context (Shopware Commercial)
Current Situation / Problem:
In B2B (Commercial) setups, there is a common requirement to send transactional emails (e.g. order confirmations) not only to the customer account, but contextually to the employee who actually placed the order.At the moment, the following limitations exist:
- employee data is only available in mail templates if an employee is present in the order context.
- The Flow Builder does not provide conditions based on employee data (e.g. “employee exists”, “employee email”).
- Dynamic recipients (TO/CC/BCC) based on variables (e.g. {{ employee.email }}) are not supported.
- CC/BCC fields can only be configured statically.
- Workarounds (e.g. separate flows per customer) are not scalable.
Proposed Improvements:
1. Extend Flow Builder Conditions
Add new conditions such as:
“Order has employee”
“Employee attributes” (e.g. email, name, ID)
Provide access to employee fields similar to existing customer conditionsSupport Dynamic Email Recipients
Enable variable-based configuration for:
TO
CC
BCC
Example:
TO: {{ employee.email }}
CC: {{ customer.email }}Recipient Fallback Logic
Allow conditional logic such as:
If employee exists → send to employee
Else → send to customerConsistent Template Variable Availability
Ensure employee is always available in templates (e.g. null if not set)
Avoid inconsistent behavior in the template editorOptional (Nice-to-have)
Introduce a recipient strategy setting (e.g. “Primary recipient = Employee / Customer / Both”)
UI support for typical B2B communication scenarios
Business Impact:
- Covers a core B2B commerce requirement (employees ordering on behalf of a company)
- Reduces manual effort in sales/customer service teams
- Prevents misrouted emails
- Significantly improves automation capabilities in Flow Builder
- Avoids the need for custom plugin development for standard use casesCurrent Workaround:
- Display employee information in the email template
- Manual routing of emails after sending
- Alternatively: custom plugin developmentCurrent Situation / Problem:
In B2B (Commercial) setups, there is a common requirement to send transactional emails (e.g. order confirmations) not only to the customer account, but contextually to the employee who actually placed the order.At the moment, the following limitations exist:
- employee data is only available in mail templates if an employee is present in the order context.
- The Flow Builder does not provide conditions based on employee data (e.g. “employee exists”, “employee email”).
- Dynamic recipients (TO/CC/BCC) based on variables (e.g. {{ employee.email }}) are not supported.
- CC/BCC fields can only be configured statically.
- Workarounds (e.g. separate flows…
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…
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 the…
1 vote -
Configuration flag to restrict update checks to the current major version
Some merchants want to remain on a specific Shopware 6.x release line, such as 6.6. A flag, e.g. in shopware.yaml, to restrict update checks to the current major version would therefore be useful.
1 vote -
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.
2 votes -
copyrightYear configurable
metaInformation has property for copyrightYear which is also printed into the storefront. But this is not configurable anywhere.
How should it work? Let us talk, maybe we can adjust the behaviour.
1 vote -
Don't use the first page of a paginated sequence as the canonical page
Use URLs correctly:
- Give each page a unique URL. For example, include a ?page=n query parameter, as URLs in a paginated sequence are treated as separate pages by Google.
- Don't use the first page of a paginated sequence as the canonical page. Instead, give each page its own canonical URL.
Currently, the canonical page in categories is always the first page. Without pagination URLs.
According to Google, the canonical URL should be set up including pagination.
Please correct this.
3 votes -
Finetune the personalized Checkout Message
Currently the checkout messages can’t be adjusted to exclude certain items or be fine-tuned. To customize the checkout message more precisely to your needs, it would be great to add further configurations to it.
1 vote -
Display filter as a checkbox without dropdown
Currently, properties are always displayed as drop-down menus in the filters. It would be nice if there were an option to display individual properties as checkboxes in the filters.
For example, it makes no sense to display a drop-down menu if a property only has one value.
It would be nice to have the option of displaying the value without a drop-down menu, as is the case with the free shipping filter.2 votes -
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…
4 votes -
Recipient "Employee" should be available inside the flow builder
Currently the recipient employee is not generally available inside the flow builder. As a new actor within the B2B suite this role should be added. So we can freely use the flow builder with the B2B suite.
The specific employee flows seem hardcoded within the B2B suite as illustrated in my screenshot. Employees do receive the correct mail, but it's not configurable/visible in the flow builder.
3 votes -
B2B Components: Show Request quote button without login
This feedback comes from a customer. They ask for the request button to be always visible, if quotes are possible.
If a guest customer clicked on the button the login request appears. After logging in the quote can be requested as usual.
2 votes -
Expose PayPal Ratepay Payment Instructions in Email Template Context
Description:
Currently, when using PayPal Ratepay (Invoice / Installment payments) in Shopware 6, the required payment instructions (e.g. IBAN, BIC, account holder, and reference number) are displayed to the customer during checkout after order confirmation.However, these payment details are not available in the default email template context. As a result, merchants cannot include the necessary bank transfer information in order confirmation emails without implementing custom plugins or event subscribers.
This leads to a gap in the customer communication flow, since payment instructions are critical for completing the transaction and customers may not revisit the checkout success page.
Expected Behavior:
The payment instructions provided by PayPal Ratepay should be accessible in the email template context.This would allow merchants to include the payment details directly in email templates using Twig, without additional customization.
Benefits:
- Improves customer experience by ensuring payment instructions are always accessible
- Reduces support requests related to missing payment details
- Eliminates the need for custom plugin development for a common use case
- Aligns checkout communication with email communicationDescription:
Currently, when using PayPal Ratepay (Invoice / Installment payments) in Shopware 6, the required payment instructions (e.g. IBAN, BIC, account holder, and reference number) are displayed to the customer during checkout after order confirmation.However, these payment details are not available in the default email template context. As a result, merchants cannot include the necessary bank transfer information in order confirmation emails without implementing custom plugins or event subscribers.
This leads to a gap in the customer communication flow, since payment instructions are critical for completing the transaction and customers may not revisit the checkout success page.
Expected Behavior:…
1 vote -
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).
1 vote -
Force customers to assign a new password after creation via the administration
There should be an option to force customers - that have been set up through the administration - to change their password after the initial login.
4 votes -
Custom Products: Add option to display configurator in a modal on the product detail page
Description:
Currently, the Custom Products configurator is rendered inline on the product detail page (PDP), typically within the buy box or page flow. For products with complex configurations and many options, this can lead to a cluttered layout and negatively impact the user experience.Proposal:
Introduce an optional display mode that renders the Custom Products configurator inside a modal (overlay), triggered via a button in the buy box.Example Behavior:
- A button such as “Configure product” is shown in the buy box
- On click, a modal opens containing the full configurator
- The configurator runs entirely inside the modal (including validation, dynamic pricing, etc.)
- After completion, the modal closes and the selected configuration is applied to the productBenefits:
- Improved clarity and usability for complex configurations
- Better user focus by isolating the configuration process
- Consistent UX pattern used by many modern configurator-based shops
- Significantly improved mobile experience (e.g. fullscreen modal)Optional Enhancements:
- Selectable display modes:
- Inline (current behavior)
- Step-by-step (existing)
- Modal (new)
- Configurable globally or per product in the admin
- Fullscreen modal option for mobile devicesTechnical Notes:
- Could leverage existing storefront modal mechanisms (e.g. modal / AJAX modal infrastructure)
- Reuse of existing Custom Products components inside the modal
- No changes required to business logic, only presentation layerPriority / Use Case:
Relevant for merchants with:- complex or visual product configurations
- multiple option groups
- strong focus on UX and conversion optimization
Description:
Currently, the Custom Products configurator is rendered inline on the product detail page (PDP), typically within the buy box or page flow. For products with complex configurations and many options, this can lead to a cluttered layout and negatively impact the user experience.Proposal:
Introduce an optional display mode that renders the Custom Products configurator inside a modal (overlay), triggered via a button in the buy box.Example Behavior:
- A button such as “Configure product” is shown in the buy box
- On click, a modal opens containing the full configurator
- The configurator runs entirely inside the…1 vote -
Individuelle Steuersätze für Kundengruppen
Individuelle Steuersätze für Kundengruppen
1 vote -
"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).
1 vote
- Don't see your idea?