In any of our D365 Implementation Projects, Solution Prototyping is one of the most important aspects of the implementation. On the one hand this Prototyping serves a common Requirement to find a solution which stays closest to Standard D365 – A Requirement often raised by small to medium sized Retailers. On the other hand, Prototyping let us fully understand D365 Retail which allows us to write the best designs for Custom solutions – An exercise which is often required for the bigger Retailers.
Solution Prototyping is most commonly done from ‘Sea level‘: by setting up D365 Retail in different ways to support variations to a Process which are then evaluated (often in playbacks to Business key users) against Process maps and related Requirements. I think this is a very good and effective way to make progress in a project while still making the right Design Decisions.
However, there are cases in which this ‘Sea level’ approach is either very time consuming or not giving you the confidence that you’ve completely bottomed out the D365 Retail capabilities to support a certain process. You probably recognise this from working on complex Processes which are Retail/Omni related, D365 MPOS/commerce customisations or Retail Integrations. For these cases, you need another approach which I’ve named the ‘Engine Room‘ approach: this approach first descends into the ‘Engine Room’ of D365 for Retail to know exactly what happens there before you work yourself up to ‘Sea level’ again to pick the best Solution for your Use Case. In this blog post, I’ll unveil all the tricks to be able to do this quickly and effectively.
Note: please ensure to familiarise with the D365 Retail API Architecture as per Part I of this series on D365 Retail APIs before you read any further.
Read more