Kurt Hatlevik inspirit365 AS Enterprise Architect(inspirit login)

I would like to provide feedback regarding the Order-On-Behalf (OBO) functionality. Currently, a customer can only be assigned to a single Sales Group, but there are scenarios where customers need to be part of multiple Sales Groups. This arises from the requirement for an n:n relationship in OBO, where there is an overlap between Sales Groups. In certain cases, businesses may have specific product assortments available through separate eCommerce platforms, where vendors/importers log in to place orders on behalf of customers. However, vendors should only have access to selected customers assigned to their OBO account. The issue is that multiple vendors may share overlapping customer lists, and the current limitation of assigning a customer to only one Sales Group makes it difficult to properly manage these restrictions.

I hope this can be considered as an additional requirement in future updates to the B2B2B functionality.

When creating record templates for customers, vendors and employees, it is not possible to edit the record template, and the user get's the error. Record template editing is not allowed for table with ValidTimeState enabled templates.

As customers/vendors/employees are the most common record types to has as a template, it makes no sense to block editing these record templates types, and I think an investment here would increase usage and reduce confusion.

See also https://fix.lcs.dynamics.com/Issue/Details?bugId=252760 originating from Ver 8.0

In eCommerce, it would be nice to have a "alert me when back on stock" feature, where the eCommerce user can receive an email when the goods are back on-hand. We see this feature available in many other eCommerce solution, and this is a requested feature.

In 10.0.44 we got the feature "Approved customer lists". But it does not with Commerce/eCommerce. Why ? We need it for Commerce/CSU also.

Digital Asset Management in D365 Commerce Site Builder lacks the search, filtering, bulk operations, and validation capabilities required for efficient maintenance of product media at scale. As a result, tasks such as identifying products missing images, replacing outdated assets, ensuring quality standards, preventing broken media links, and cleaning up unused files become highly manual and error-prone.

This gap reduces productivity for merchandising and content teams, impacts time-to-market for new products, and increases the risk of poor customer experience (e.g., missing or low-quality product images in the storefront). To address this, we propose a set of targeted improvements

:

• Robust search and filtering (including “products without images”)
• Bulk upload, bulk tagging, and bulk replacement
• Dashboards for missing or low-quality media
• Metadata, tagging, and version control
• Media quality validation and AI-assisted automation
• Orphan asset detection and cleanup tools
• API and integration enhancements for PIM/DAM connectivity
• 
  

Together, these improvements will reduce manual effort, increase data quality, improve storefront consistency, and significantly streamline ongoing product media maintenance in D365 Commerce.

Each time you load a D365 form som scratch(CTRL-F5), and you take a view in F12, you will see that there are a lot of calls happening, but one of them, that often stands out are App.Css.

At live customers where we see download time of vary from 3s to 12s, and it’s size is approx. 15.9 MB. My experience is that if this file is downloaded slow, then users complain about performance issues, and that the F&O feels “sluggish”.

You can try it out on your own environment by going to :

[Your F&O URL]/WebContent/ApplicationSuite/less/21/0/app.css

See https://kurthatlevik.com/2025/11/23/d365-and-the-performance-of-app-css/ for additional details.

Put bluntly: no enterprise web application in 2025 should ship a 15 MB uncompressed render-blocking CSS file, and F&O is long overdue for a cleanup here. Microsoft can dramatically improve perceived performance across all customers by modernizing static asset delivery for these core UI bundles.

To put the impact into perspective: today a 15.8 MB uncompressed app.css over a typical 15–30 Mbit/s corporate connection costs roughly 4–9 seconds of pure transfer time on every cold load — and that’s before the browser even starts rendering the UI. The same stylesheet, if split and compressed down to ~2 MB of critical CSS, would load in well under a second on the same line speed. With proper client caching on top, most users would pay this cost once per update, not once per session. In other words, a trivial change in how static assets are packaged and cached would turn “wait 5–10 seconds for the client to wake up” into “page is ready almost immediately” for every F&O customer on the planet.

We need API-level support in Site Builder to automate the maintenance of product images in the media library.

Our media library currently contains more than 55,000 images. These have been manually uploaded over time, and many are now outdated. With the volume of products we manage, manual updates are no longer sustainable.

We regularly receive feedback from customers and suppliers when old or incorrect images appear in the webshop—for example, seasonal packaging from previous years still being displayed. While we update these manually when discovered, the current process does not scale.

Our external image bank provides event-based alerts whenever product images change. To respond to these updates automatically, we need Site Builder to expose APIs that allow external systems to interact with the media library in a controlled and supported way.

Specifically, we need API capabilities to:

1. Check whether an item currently has an image stored in the media library (for example by searching for filenames that include the item number).
2. Retrieve the last-modified timestamp of an existing image (filename-based or metadata-based).
3. Delete image files associated with a specific item (filename-based deletion is sufficient).
4. Upload and publish new image files with defined metadata.

With these capabilities, we can implement a fully automated process where product images are kept up to date the moment they change in our external image bank. This would ensure accuracy, reduce manual workload, and prevent outdated visuals in our webshop.

Adding API support for these operations in Site Builder would bring Dynamics 365 eCommerce in line with industry expectations for automated product content maintenance.

Thank you.