1533 results found

1. Improve checkout message performance

   The AI-generated checkout message sometimes takes 10 seconds to generate if there are many products in the shopping cart.

   Many customers close the page during this time. It would be better if the messages were generated in the background beforehand or if a faster AI model were used.

   3 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  AI  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

2. 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… more

   2 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  App System  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

3. 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:

   1. Go to checkout.

   2. Select country.

   3. Enter an invalid value in the “Postal code” field (e.g., asdasd or asd123).

   4. Leave at least one other required field blank.

   5. 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:

   1. Go to checkout.

   2. Select country.

   3. Enter an invalid value in the “Postal code” field (e.g., asdasd or asd123).

   4. Leave at least one other required field blank.

   5. 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:… more

   4 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Checkout  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

4. 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

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Other  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

5. 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

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Content management  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

6. 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.

   2 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  AI  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

7. 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.… more

   3 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Orders & Customers  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

8. 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 deletion

   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.… more

   •  

   2 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  B2B  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

9. Let B2B Employees changed their own password

   It should be a standard functionality that a user can change their password.

   This is currently not possible.

   Please implement this.

   2 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  B2B  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

10. 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… more

    3 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  B2B  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

11. 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… more

    3 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  System & Settings  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

12. Filter visibility by selected sales channels

    For products, there is an option to set visibility for selected sales channels.
    
    This setting determines whether a product appears in search results or in the product listing.
    
    However, to see what is set for a product here, you have to open the product page and then click the settings button again.

    It would be nice to have an option right here in the product overview to filter by visibility settings.

    2 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Products, Prices & Properties  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

13. Allow for CMS elements to be hidden on category pages when product listing page is not the first page

    When a category layout contains some text or images together with the product listing element, that text or element may be indexed by search engines multiple times for each page of the listing, leading to duplicate indexing and results.

    It would be helpful if certain elements could be hidden once the customer or the indexing bot navigates through the listing pages, or a URL contains the ?p= parameter. This would prevent redundant indexing.

    2 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Content management  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

14. 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

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  System & Settings  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

15. payment method per customer

    Default payment method should be available per customer so that we can use this information for
    - customer account
    - Reports
    - order confirmation

    2 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Orders & Customers  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

16. 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”, or

    an 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… more

    2 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Checkout  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

17. 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 them

    The 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… more

    3 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  B2B  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

18. Increase value for "items per page" on customer > addresses (make it configurable)

    Increase value for "items per page" on customer > addresses:

    • Add values "250" and "500"
    • Make default value for "items per Page" configurable so it can be set to <>25
    2 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  System & Settings  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

19. 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… more

    5 votes

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Orders & Customers  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

20. 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

    Vote Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  B2B  ·  Delete…  ·  Admin →
    How important is this to you?

    Nice to have You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating