SCC FeedbackWe value your input! Tell us what you think about our Sana Commerce Cloud roadmap initiatives and the direction we're taking. If there's something specific you'd like to see, don't hesitate to share it with us below. Vote for ideas on the page to let us know what you find important. You can vote by clicking on an idea and then click thumbs up, down or neutral.
Admin
User Accounts
Content
Discovery
Products
Basket & Checkout
My Account
Marketing
Registration request instead of full ERP registration
Some of our clients have expressed their preference for a streamlined registration process without creating a customer account in the ERP system. They would prefer to receive an email notification through a simple form, rather than dealing with the hassle of using type forms and relying on another third party platform. To address this, we are now offering the option to choose between customer registration or email request in our registration configurations.

We have received additional feedback from our customers, who suggest that the registration in the ERP system should only occur after approval. This approach has proven to be more effective, especially in filtering out fake or irrelevant registrations. However, in cases where the registration is deemed valuable, it is still a convenient way to seamlessly integrate them into the ERP system without manual intervention.

Therefore, we highly recommend adding the customer to the ERP system upon approval in SANA, with activation taking place after verification and completion of the client's information in the ERP system. This will not only improve the registration process but also ensure the quality and accuracy of data in your ERP. Thank you for considering this suggestion.
13
Add "assortment" to the Authorization related to sub-accounts
As an accountmanager (shop account) I want to have the possibility to autorize the productgroups that the sub-account can view and order. So for example, my technical employee can only see and order technical products.
1
Customer first and last name separated
As a webshop manager I want my registered customers to have their first and last name split in the webshop, so I can use the first name separately in for instance an e-mail or text message. 
In a B2B environment, it would be desirable to receive additional information about the contact person during registration, in addition to the company details. Currently, only the e-mail address is available here. To address the customer, however, a salutation would be useful. First name and last name are also not always available from the e-mail address.
4
Shop account / sub account setting for 'can place quote'
Currently Sana only allows a setting Can order=yes/no on the shop account. The quotes just follow this permission. However, B2B companies want some customers to only create quotes and some customers to only create orders. 
3
Address verification
Invoice and shipping addresses should be verified. Now a customer can enter a false address or can easily make a mistake entering his address.
13
Request acceptance of the Privacy Notice on the final customer's first access to the portal
Request the acceptance of the Privacy Notice in the first access of the end customer to the portal. It is important to notify the customer about our privacy policies, as well as the treatment of their information.
4
Redirect cuistomers to locale language
If a user has a locale of e.g. fr-fr but the default store language setting is e.g. en-GB they should be asked whether they want to be redirected to their default language, if it has been installed in the webstore.
2
First name and last name of the contact person in the B2B registration
In a B2B environment, it would be desirable to receive additional information about the contact person during registration, in addition to the company details. Currently, only the e-mail address is available here. To address the customer, however, a salutation would be useful. First name and last name are also not always available from the e-mail address.
5
B2B request shop account if ERP customer exists
It would be useful for our B2B customer to be self register their ERP accounts. This should be controlled so that if a customer registers and enters their Customer ID from our ERP, we get an email to confirm or reject it. This would stop duplicate ERP accounts. 
17
Impersonate shop accounts without order placement
As a web store manager, I want to be able to give my account managers access to impersonate customers without the capability to place or edit orders, or any other admin access. This will enable them to assist their customers and view their customer's orders & documents in the same way that their customer can.
2
Email Notification for B2C Registrations
As a webstore administrator, I would like to receive an email notification when a new B2C user registers for a shop account.
3
Enter ERP Account ID as part of Sign-Up
If customers already have an account in our ERP and signup to the website, this creates a brand new customer record in the ERP database. It would be useful if part of the registration page if the customer could enter their ERP account ID and then it sends an email to an admin to approve the account. This would stop the creation of duplicated records in ERP.
10
Customer segment by Customer Shop Account Type
It would be good if we could create a customer segment based on the shop account type Regular/Manager/Sub Account. This would enable us to add or hide items based on the account type. This would be especially useful when editing the 'My Account' menu items - we could use the segments to show/hide custom items.
Sub accounts - allow to pay online
Right now B2B sub account feature cannot be used in connection with online payment. Reason is due to the authorization.
Suggestion:
- MVP: make online payment allowed for sub accounts, but hide the feature to set order budget limits to stop the authorization.
- Long term: for authorization orders, treat them similar to offline orders where the order payment email is sent after order goes into approved state (also stop allowing the managers to reject already approved orders).
1
Sales agent specific product assortment
Requirement
-----------------
In B2B businesses, sales agents play a big role. In such cases, there are some products that customers should not be able to see or buy, but sales agents when placing an order on behalf of the customer should be able to add to the order (usually products that need expertise in choosing or need technical knowledge to understand related components that should be bought with it).

Proposed solution
------------------
1. Simple approach - Setting on stock and assortment to set the sales agent assortment setting (complete / additional / customer specific). Additional and customer specific should work the same as now, where the complete should show all products. However, if the Customer assortment setting in admin is Additional or Specific, and the SA setting is Complete, then system should indicate per product whether it is Not applicable to customer or not.
2. Medium approach - Add a setting in the ERP item master called Sales agent only, and return this to Sana. Use this as an additional filter on the product search query in the web shop (also with customer assortments). End result should be that when an SA represents a customer he sees both the customer's assortment + any SA only items.
3. More configurable - Extend the standard customer assortment functionalities (in Sana and the ERP) to support configuring product assortments at sales agent level as well.
Login / Impersonate
Please add the latest login on the shopaccount page OR add the impersonate button under Sales Statistics
When monitoring you can see when a shop account was logged in but if you want to check why they didn't order you have to go to impersonate to check their basket.
1
Sales agent - max stock level display setting override
In stock levels, there is a setting to configure a max stock level which results in the stock text displaying ">1000" for example without showing the total stock amount which is 25,000 in stock.
This is a global setting right now, but one of our customers suggested that it would have been much more B2B oriented if there was a setting to control whether or not this should be also applied when a sales agent is representing the customer.
Their argument (business), is that the sales agent is their own employee so it does not make sense to hide the full availability to them.
SSO with SAML
Standard Sana currently supports SSO with OpenID connect only. But some of our clients wish to stay with SAML for specific reasoning / or preference from their architectural teams.
Request:
- Make SAML and option or at least provide extensibility to apply SAML for custom projects.
Admin Users login timeout
As a Digital Marketing Manager and Sana eCommerce Administrator I want to have the ability to configure Admin level users a login timeout that is more than the Sana default (preferably a daily timeout or multiple days timeout), having to login multiple times a day is frustrating and time consuming.
3
Option to disapprove accounts
It would be nice to have the ability to disapprove the store's accounts. Now we have the possibility of approving them, but if we want to disapprove an account again we have to request it from SANA support.
1
User only sees their orders, offers and delivery notes
It would be beneficial to manage the visibility settings of sales documents from the user account settings. Users should have the option to view only their own orders, offers, and delivery notes, or to access all company information. Additionally, it would be useful to hide invoices so that only users with the appropriate permissions can see them.
2
Disallow Pre-order for B2C customers
Please consider making it an option to disallow pre-order for b2c customers. Right now, if pre-order is enabled in the ERP, it applies to all customers. In our case, we would not like to only allow business customers the possibility to order items that are out-of-stock, as they will be more understanding of potentially long lead times.
Newsletter opt-in when registering
The possibility for a customer to choose whether the customer would like to receive the newsletter during the registration of a new account.
4
Accept terms and conditions during registration
The possibility for a customer to accept terms and conditions when registering a new account.
3
Show all added items in cart, regardless of who added
Currently the cart will only show the items added by the individual user when they login or represent an account.
In our daily business we have approximately 90% returning customers. They often call for personal product advice. We then use the impersonate function to add a product for the customer to that cart.
We would like to see all items in the shopping cart, regardless of who added the item. So an overview for the account representative of all products added by all shop accounts for one (ERP) customer.
8
Allow lo restrict sales documents visibility for Sub-accounts
As a webshop manager, if I have enabled account management functionality, I would like the account managers to be able to select whether each sub-account of the same customer can see all customer's sales documents or only the sales documents created by them.
B2B Registration Additional Questions
When new B2B customers register, we would like to ask additional questions (for example, details of trade references) which are not fields in the ERP system. This is so we can assess the new customer and decide if we approve the registration or not.
These answers should be shown in the internal email when a new customer registers, and ideally stored as comments in the ERP system.
2
Login API
Use Sana as the IDP for logging into other shops within the same Sana instance (without using external IDP SSO).
External APIs - Shop account creation
It would be good if Sana can provide an API which allows creation of shop accounts.
This should ideally work also for Customer accounts which have not yet been indexed (i.e.: do a real-time ERP call prior to the shop account creation logic).
This should ideally be in a common format (e.g.: JSON).
This should ideally provide back a success or error response.
1
Limited Rol [Quote placement / Quote conversion on account level]
As a user I want to be able to see prices, stock and create a quote, but I should not be able to convert the quote to an order. My supervisor, or a colleague with different permissions, can convert the quote to an order. There should be increases possibilities to manage such kind of access and restrictions within the store.

Can be good idea, have Limited Rol that can watch prices, watch available and create a Car and Quote. Without create o converte Quote to Order. The Customer Rol can enter to covert this Quotes created by this new Rol in Orders. On this way the clients can have more users with acces, restrictions and security in the store. And uniquely the Customer Rol have permissions to create Order as a Master Rol.

The clients could have more visivility about the products and requestes, but with restriction


Remove the restriction in SSO that requires multi-lingual shops to register all language slugs in IdP
In the SSO configuration we currently expect that "If you have a multi-lingual webstore, you need to add all webstore URLs for all languages" (see article: https://support.sana-commerce.com/Content/Sana-User-Guide/Customers/SSO/Microsoft-Entra-ID.htm).

Not all custom OpenIDConnect systems might support this.

This is done for additional security, but since it is just a language difference the customer was inquiring whether it makes sense. Suggestion is to remove the language part and allow to just use the base URL only for the call back.




E-Mail to new customers in correct language
When uploading new customers they will receive an e-mail 'Welcome to shop [SHOPNAME]'
But this is always in the default language of the shop.

When uploading or creating new customers you should be able to define in which language they will be supported.
1
SSO improvements - refer email first then preferred user name
In our standard SSO it seems (according to TC) that Sana first looks at the preferred user name in the token response and the email second.

When we discussed with our customer (Palfinger) they were of the opinion that this was not correct. The system can return any name as the preferred user name as the one they use. It does not have to be email. So, better way would be to refer to teh email instead since we need it for Sana.
SSO feedback - not necessary to configure separately for each lang key
In the standard SSO configuration in Sana, we expect the customer to configure all the language URLs also in the IDP Separately.
We have this configuration restriction to ensure and secure that we can allow all possible domains.
But it doesn't make sense to configure 6 URLs with only the language part changing.

@Volodymir Labensky is already aware I chatted briefly with him.

Case = Palfinger
Ability to see in customer card on ERP if there's already a shop account
I would like to see in the ERP (D365 BC) on the customer card or contact card if the customer already has a shop account.
4
SSO integration into the website instead forward to the external authenticator website
All single sign-on methods forward the customer to the authentication provider's external website.
This can lead to confusion among customers, as non-technical customers are not expecting another website to open to enter their login credentials. Also, with increasing phishing and security training for B2B customers' employees, they are more suspicious than in the past. This also feedback from our customers

The username and password fields should be natively integrated into the Sana frontend for a much better customer experience.
Also, PWA is not working when using the SSO.

example of ADB2C integration, search for: Embed Azure Active Directory B2C user interface into your app with a custom policy - Azure AD B2C | Microsoft Learn
Sub account control on whether or not to have authorizations feature
Some of our clients want to use the sub account feature. But they do not want to use the order authorization or budget control process.
But in standard Sana, it is not possible to block the auth process for account managers. This is risky for the web shop owners because they cannot predict how the customers will use this feature which results in Orders sitting in the ERP pending approval.
So it is better if we had a switch to toggle (global / or shop acc level - preferably both) whether the admin can control the availability of this setting.

Usecase raised by
--------------------
Teufelberger
cust_ids claim transformation
Is it possible to add the functionality to the Sana site, that the cust_ids claim can be returned as a string with several cust_ids, instead of a collection type?

In Azure B2C directory it is not possible to create a custom collection type. We would have to create a Custom policy that breaks up the string and transform the contents into several attributes / claims then add it to a collection claim during runtime.

That is a lot just to achieve the one to many relation for a shop account to customer ids.
I was thinking that if a string has a certain format, then Sana could read it as a collection instead.
Area Manager option in the Shop account type
When setting up company employees in 'Customers - Shop accounts', there are currently two options to represent customers which are Linked and All customers.

This is fine for our sales agents (linked) and head office admin users (all) but would it be possible to add a third middle level option of Area Manager and allow multiple sales agent codes so that the user can only view & represent shops they're sales agents are responsible for rather than every customer code?
Powered by airfocus
SSO improvements - refer email first then preferred user name
SSO improvements - refer email first then preferred user name

In our standard SSO it seems (according to TC) that Sana first looks at the preferred user name in the token response and the email second.



When we discussed with our customer (Palfinger) they were of the opinion that this was not correct. The system can return any name as the preferred user name as the one they use. It does not have to be email. So, better way would be to refer to teh email instead since we need it for Sana.

0
0
0