As I prepare for my Dynamics 365 certification in sales (MB 210), I’m creating blog posts based on my revision. I hope that collectively these posts may prove useful to anyone also preparing for the MB 210 exam. This time I will cover the concepts around the product hierarchy.
Below you can see the skills measured statement that refers to the product catalog. From this we can learn that the product catalog covers many topics including product families, bundles, price lists, discount lists and much more. Because of this I intend to take several posts to cover all of the details connected with the product catalog. In this post I’ll cover the concept of a product hierarchy.
Within Microsoft Dynamics 365 it is possible to view product families, bundles and products in a hierarchal manner.
Note: A hierarchy is effectively a “special” self-referential relationship. I’ll discuss this concept a little more later in this post. As it might be useful to know that we can apply a hierarchy to other entities!
Hierarchal information is displayed in “tiles” showing how each element of the product catalog relates to each other, it is also possible to trigger specific actions directly from the tiles. This helps users to quickly see all of the products the company sells and how they relate to each other.
The hierarchy view is opened by selecting “VIEW HIERARCHY” in the command on a product, product family or bundle.
It is also possible to access the same hierarchy view directly from the product form.
Once the hierarchy view is selected you will see a representation of the product catalog structure using tiles for each node. On the nodes you can see key information such as product name, ID, type and status.
On the left hand side of the screen we have a tree view to help navigate the structure. The “+” and “-” buttons can be used to expand or collapse “legs” of the chart.
Also notice that the form currently displayed (for the tiles) is the “Product Hierarchy Tile Form”. You can have multiple available forms and users could opt to change which form is used to display the tile information as required.
On the screen shot above the “Canned Goods” product family has 5 tiles directly associated with it. But only 3 can fit on the screen. (The number of tiles that can display at once may vary depending on your screen resolution.) If this happens you will see a counter on the right hand side of the form and a “>” symbol. This can be used to move to the right to view additional products. (And of course the same happens on the left side after you’ve moved to the right!)
Notice above that I am showing a product bundle called “Canned Goods Bundle (Veg)”. The bundle will be made up of a number of other products. When bundles are shown we see where they sit in the hierarchy but we don’t see the products that make up the bundle. If you need to see the contents of the bundle then open the bundle and view the “bundle products” sub grid on the form.
If you dip into the structure part way down, you might see an ^ icon that allows you to move up the tree. (As shown below.) This will allow you to navigate up the hieratical structure.
Having created your product catalog this final concept of navigating the hierarchy is pretty simple. A few minutes “Playing” with the capabilities should be all you need from a revision point of view.
For the exam you should be aware that this style of hierarchy view is available (out of the box) on other entities. Such as an account hierarchy. It is also possible to create custom hierarchies as required.
How to Create / Edit a Hierarchical Relationship?
Note: I am covering the basics of creating a hierarchical relationship I am not sure if we’ll have questions on this in the exam! But in my revision, I felt it was best to be prepared!
Firstly, ONLY one relationship can be defined as being hierarchical on an entity. It also needs to be a relationship with the primary entity and related entity as the same entity.
For example, parent account on an account. As shown below.
Quick Tip: You will find that you cannot amend existing system relationships, meaning you will need to create fresh custom relationships. This came up recently for me! As the case entity has an out of the box concept of parent case. But this relationship is not marked as hierarchical and cannot be changed. Therefore to show a case hierarchy you’d need to create a new custom relationship.
Next we can use the hierarchy settings to define how this relationship will behave. Note, each entity has one entry for hierarchy defined. By way of an example the hierarchy setting on account is shown below.
Notice that I only have an edit option. If a hierarchy setting didn’t yet exist a New button would also display.
On the hierarchy setting we can see that the default quick view form is defined. It is this that decides how the “cards” in the organisation view should appear. Whilst the hierarchy can’t be changed you can amend the hierarchy form or create a new form as required.
At this point it should be enough to know that in the hierarchy settings we define which quick view
form will be used to display the tiles in the hierarchy. And that the fields shown on that form can be customized as required.
As part of your revision for the MB2 210 exam I encourage you to experiment with as many of the options within the product catalog as possible. Hands on experience is important! Enjoy.