Designing Headless Commerce Starts with Data — Not Apps

It doesn’t matter if I speak to e-commerce gurus or leaders in App development, they all say the same: the difficulty is not making the Apps or customer journeys. The difficulty is in getting the right data, in the right quality.

This is even more urgent in Headless setups. Headless Apps do not have any data or local business logic. They live by data and services from backend systems like Dynamics 365 ERP and Dynamics 365 CE (CRM).

In this blog post, we’ll see how we can overcome these hurdles.

Hurdle 1 – Exposing the right data right

In the ideal world, UX designers are in the lead when Apps, portals or any customer oriented systems are built. Side note here is that I recommend to converge customer and employee oriented apps, but let’s put that aside. In how many Dynamics 365 implementation projects are UX designers in the lead when it comes to customer oriented scenarios? I didn’t come across many in my 20-year career.

Let’s revert the question. How can we put UX designers in the lead?

My answer:

1. Start with the journey. Let the UX designers design the optimal customer journey first and then map to Data and Services. Not the other way around. Literally map a wireframe to APIs. Please note that this requires your API providers to be very experienced in both the backend system (like D365 ERP) and API domain.

2. Enterprise API library. Publish core/key APIs in an enterprise API library. Ideally even before wireframe design begins. My best practice as I already described in my blog post in 2022: describe your D365 APIs in the OpenAPI standard and publish them on Azure API Management.

3. Publish the OpenAPI specifications. Use APIM Developer portal or Swagger portal to deliver the API specs to your App/portal developers. See some examples below which combine APIs based on D365 Commerce and D365 ERP:

4. Composite APIs. In many cases, UX designers design grids with data which is exposed by multiple APIs. For example, Sales order line information combined with product data. My best practice: combine them in a composite API to make life easier for the developers. The “individual” APIs and “composites” can co-exist in your API library!

With the wireframe mappings and documented APIs in the bag, frontend developers can now automatically generate code to consume the APIs. This will allow them to autonomously support your UX designers!

Hurdle 2 – Exposing data in the right quality

If your PDM/PIM data does not contain the right product descriptions, categorizations or translations, it can negatively impact your customer experience. No matter how strong your UX/customer journey is designed and implemented. In headless Apps, frontend journeys may even get broken returning no data at all!

So, the key question is: how can we guarantee data quality? My best practices:

1. Identify your critical data. Identify backend setup and master data which is critical for your customer journeys. You can easily derive them from your wireframe/API mappings. Map these requirements back to the data and processes in D365 ERP and CRM or other backend Apps.

2. Prevent errors by a strong process foundation. Educate the responsible business owners properly. Make them understand what the impact of their actions is on data quality.

3. Deploy a Data Quality framework. Utilize Synapse link or Fabric link to export your data to Azure Data Lake. Use Azure Data Factory to process the data and identify errors and warnings. Write these errors and warnings into tables. Surface the errors and warnings in Power BI Reports. This is your feedback loop into #2, the BAU processes in your organization.

4. Deploy a Data Quality agent. Let Data Quality agents work with the errors and warnings to assist your users to resolve the error. Agents could suggest data actions, such as unpublishing items from assortments if they are missing critical data or prices. As a next step, Agents could even resolve the actual issues utilizing Dynamics 365 MCP server.

About the Author

The further I progress in my career, the more I see that the most successful IT projects aren’t feature driven. The most successful projects have a holistic view, acknowledging that downstream success can depend on upstream quality and structure.

Connect with me directly on LinkedIn if you want to know more.