Following on from my previous post of an infographic detailing some of the improvements in the Product Catalog in CRM 2015, this blog post aims to go into more detail and provide some advice on how to get the best out of the new product catalog out from a configuration point of view.

Using the infographic as a base, I’ll springboard off that to form a structure to the post. The Product Catalog in it’s own right can seem a bit confusing before the updates, but this post is not going to cover too much old ground and really only build upon what was the older version of the Product Catalog to remain consistent in it’s aims. However it is simple once you have a play and understand how the different elements all build on top of each other to form an extensive configurable way of keeping sellable items in a system.

The improved Product Catalog in CRM 2015 goes above and beyond just keeping sellable items in a system by applying a structured family hierarchy and giving it the necessary tools to improve selling on the front lines for the sales person & other users building the opportunities, quotes, orders and invoices.

In brief, some of the most notable and exciting functions are the visual hierarchy, the ability to add attributes to a product and configure them so they are either set automatically or must be set by the user adding the product to an opportunity, and the product relationships which you can specify if they are one way or two way.

Keeping with what you know..with a few changes

Instances of Products still remain on Price Lists in the form of Price List Items but there are a few tweaks. The Product Catalog has slightly changed to include the ‘Families’ aspect now.



Updated top menu bar & new out of the box Views


To furthermore reinforce the new structure and elements introduced in 2015, you also now have some new Out of the Box views, such as ‘All Products, Families & Bundles’. This is because you can create different types of product now: a product family, product or bundle shown at the top of the above screenshot. You can see the difference in the icons below:


Different icons are visible on some views. You can hover your mouse over the icons and it will tell you what they are, and you can also click the hierarchy icon to launch straight into the visual hierarchy functionality for the selected item.


The icons can be hovered over to see what they are, or just check the column ‘Product Structure’ out and it will tell you what it is. Product Families, Product Bundles & Products have the visual hierarchy attached (only if they are linked in a product family)  so you can go ahead and click that second icon to the right to be launched right into the hierarchy of the selected family or product.

Also you now have different statuses of all three of these, the two main ones being Draft and Active. You can only add Active products to an associated record such as an Opportunity, yet you will be able to search them in the lookup, they won’t be immediately available in the quick view. If you are creating a product that does not have a product family associated to it you can configure it so they are always created in Active state in the system settings / sales box.

The other interesting status is Under Revision. If you have an active product and want to make changes to it, you can click ‘Revise’ which changes the status to ‘Under Revision’. A user can still add the old product to records. You then have two choices, you can Publish your updated changes and this will make your changes live. The alternative is you can Revert your changes if you no longer want to keep them to go back to the earlier version of the product.

Lastly, you can Retire a product to change the status to Retired to make it no longer available for selling.

If you wanted to make changes to a product but ‘take it off the shelf’ so to speak, I would say Clone that product which creates a copy, Retire the original version of the product and configure your new product that has been created in Draft state which is unavailable to users at the moment. Once you have completed this you can publish your ‘new’ version of your product.

Improved Structure

Product families can be compared to an abstract class. You will never use it and you can’t use it in a price list, however it’s children will inherit it’s characteristics.

When creating a product, you have the choice to set a ‘Parent’ option which is essentially the  ‘family hierarchy’ in the lookup field specified on the product (see below). This becomes read only once the record is saved and can no longer be changed once it has been created. Once created, the name of the field changes to ‘Family Hierarchy’ whether it has a value in this field or not.


New ‘Parent’ lookup field on the Product


When you click on the product lookup, you’ll be taken to the view of only the product families, you can change the view, but you can only select a product family to be as the parent, not a bundle or another product, if you do you will receive the error below. This creates the scenario that essentially the product families act as a hierarchical structure to your products and you would need to set these up first before anything else if you intend to use them


Error when trying to select a record other than a Product Family as a Parent to a Product


A Product Family has product properties (I’ve been calling them & refer to them as attributes) which are basically like you giving a class attributes in development, and it is much akin to creating new fields in the back end configuration of CRM, except more onthefly and actually inside the user interface, it’s really quite awesome. Product Properties have a backend and a frontend purpose. In the back end you specify the type of field, and depending on that type you can then specify other things such as max characters, etc. but you can also specify a default value for it, however this is not mandatory, and by leaving it blank you are prompting the user adding the product to fill it in at the front end.

In the screenshot below you will see the product family ‘CRM Service’, it actually has a parent called ‘Office 365 Service’ but that will be discussed in just a moment. You’ll notice it’s properties, specifically the ‘Base Language’ and the ‘Organisation Name’. Base Language has a default value of English and Organisation Name does not have one, so prompts the user in the front end to fill this in, which you will see in the second screenshot below this one.


Product Properties: The two discussed are ‘Base Language’ which has the default set as ‘English US’ and ‘Organisation Name’ which has no default set but is set as ‘Required’. This means in the front end forms, a red cross will be displayed when this product is added to the table as a prompt for the user to complete the details.



The Organisation Name is required here (& also the Size) to remove the red cross on the grid. A user can still save the record with the red cross and does not prevent this action from occurring.


Now one of the really interesting things is that just as a class inherits from an abstract class in development, a child family product inherits from it’s parent, and it supports more than one form of inheritance, so you could have a parent with two attributes (or properties), then it’s child will inherit these properties but add to itself 3 more, a child of this child will now have 5 properties/attributes from inheritance, and so on. Depending on which family your actual real product is associated to will depend on what attributes your product inherits. If a product was attached to the first family (by specifying the product in the family section at time of creation) it would inherit 2 attributes/properties, however it a product was added at it’s second child, it would inherit 5 attributes/properties.

You can see the visual hierarchical structure by selecting the icon in the view or the ‘view hierarchy’ in the form view, and you will be taken to the second screenshot below. You can see that families, bundles and products can all be viewed here depending on their placement in the hierarchy, but you can only see three deep at a time, and you can only see three across at a time. You need to scroll down or click the ‘>N’ to the right if there are more than 3 on the same line.

You can also see if a product is in a family hierarchy on a form by looking at the lookup and the families are split up with chevrons > between them.


When set, the ‘Product’ field turns into the field ‘Family Hierarchy’ and is read only. You can see the hierarchy where the Product Family records are each separated by a chevron. In this example, there are two Product Families in the Hierarchy that is associated to this Product.



The Visual Hierarchy. On the left is your hierarchy but in list form. You can click the ‘pop out’ icon to open the record of one of the cards. The Visual Hierarchy only displays three levels down and three cards across, you can scroll down to see the rest of the hierarchy if it spans larger than this, and you can scroll to the right where there is a chevron ‘>’ and number, indicating how many times you would need to click to scroll and see the remaining cards on that line.


Enhanced Ways of Selling

So we have already touched a little bit on Product Properties however I wanted to discuss these a little bit more and show how they are useful to the front end user.

  • A product can only have properties/attributes if it is linked to a family hierarchy. If it is not, it can not have attributes/properties and the ‘+’ icon will be unavailable.
  • You can edit the products individual properties/attributes, just like in object oriented programming however, an objects attributes themselves can not change, they are defined at the class level, meaning you can not add or take away attributes of the product level. 

You can however, overwrite/override the properties at the product level instance, again just like you can edit the attribute values of instances of objects, you can do the same for instances of products as well. Then the subsequent price list items of that product will have those attributes. This is discussed a little further below.


The types of field available to Properties of Products



A mash up of the screens of different types of option set selected for ‘Data Type’ and what the resulting options would be depending on that Data Type. Optionset acts a little differently as you can add new options to the sub grid to create the option set for the user that they will see in the front end. The options you create has a value which is editable, just like option sets in the back end.


In the screenshots above, you will see the different options available for the ‘Data Type’ of a property. I have collated the screens to show you the difference between all different types based on this optionset’s selection. You may notice that the option set type acts a little differently as you need to save the record to then add the associated options into the sub-grid. The default value is then a lookup to the records you have just created in the sub grid.

Whilst you cannot edit the number of properties a product inherits, but you can edit it’s settings and default value. By overriding the property you can essentially change the name and basically everything except the data type of the field. You do get a reminder about which base type this inherits from, so there is always traceability, but to be honest this could get quite confusing if used often so I would recommend you use this with caution, perhaps only if your not using the actual hierarchical system and have a dummy parent. (now that’s an idea I will play around with!)

At the form level of the product you can see if a property has been overridden as the ‘Override’ icon will appear beside the property as the icon on the subgrid.


By clicking on a property in a product and opening the record’s form, you will have the ‘Override’ option available to you at the top



Once you have clicked Override at the top of a form, you will see this warning. By clicking ‘Override’ you will be able to edit the fields of the opened property except the Data Type. If you edit even one field, and save the record, navigate back to the original product form, in the Product Properties you will see the Override icon next to this property as an indication of your edits. You will see the base property from the family hierarchy you edited from in the ‘Base Property’ view on this form also.


The properties are translated back to the user who is building the opportunity, quote, order or invoice under the ‘properties’ column in the product view on the form records. They appear as a red cross when you first input the product if there is information that needs to be completed. You can still save the record if you do not enter the details and it will still calculate the revenue. Also you can not edit the price per unit line, and must edit the discount field instead if you want to change the price.


The red cross in the product table is an indication of there being properties of the products that require data to be entered. The user can still save the record without making these updates.



A larger view of the Edit form on the product line.


You can create a bundle by clicking ‘Bundle’ at the top of the products view. You do not require a parent before you can add products to the bundle. A bundle has a subgrid called ‘Bundle Products’ on the form, click the plus icon to the right of  it to create a new association between the product and this bundle. This is where you specify the quantity of the product you are adding to the bundle. You can add products from any family hierarchy.

When a user adds a bundle to the product table in a record, it displays the contents of the bundle in indented lines below, and just like a single product, if you need to add details in the properties then it will highlight this line per line, and the parent line (the bundle itself) won’t be green until all of it’s associated products inside are green.

Remember you still need to add instances of the Bundle as price list items on price lists to be able to add them.


In a Bundle, they have an extra sub grid called Bundle Products, where you add the products by clicking the ‘+’ icon to the right of the sub grid, specifying the product (which can be from a different family) and the quantity



When you add a product bundle into the product lines of a form in the front end system, the items of that bundle are listed and intended. The product properties and suggestions work on a line by line basis so any required information will be indicated on the specific lines with the red cross. The entire bundle will remain with a red cross until all it’s associated lines are green.


Lastly, there is a new association called ‘Product Relationships’. This is where you are essentially taking advantage of a manual N:N relationship between Products. Only Products and Product Bundles can have relationships not families..

You can create a new product relationship by clicking on the ‘+’ icon next to it’s related sub-grid further down the form, or by clicking on the associated arrow in the navigation and selecting ‘Relationships’ and selecting ‘Add new Product Relationship’. Either one of these options causes the quick create form for product relationships to drop down and you fill in the ‘Related Product’, the ‘Sales Relationship Type’ and the ‘Direction’. Product Relationships are based on their line and depending on your selection, it means the following information is displayed to the user when they click on the ‘suggestions’ hyperlink in the product line as a pop-out form. There is four sections to the form based on the four available option-sets in the relationship so it is scrollable:


When you hover over a product line, you will see the ‘Suggestions’ hyperlink in the right hand ‘Suggestions’ column appear. Click this link to open the suggestions pop out form.



When you click suggestions a pop out scrollable form appears which these two screens form a part of. Product Relationships set at the product or bundle level appear here based on the option set selected and also if it’s bi or uni directional. To select any suggested products or bundles, over over the line and select ‘Pick’ which will appear and there will be a count incremented at the bottom of the form. Once completed, click ‘Add to List’ at the bottom to add the picked products to your table.


The option-sets relate to the grids they display in to the user, up-sell, cross-sell, accessory and substitute but you can also specify the direction, uni-directional or bi-directional. The direction will display both ways if it is specified as bi-directional. If you specify product X as Product Y bi-directional, they will refer to eachother under the suggestions when selected,  but if it was uni-directional, it will only go the way the relationship is specified.

Hover over the item in the form, and you will see ‘Pick’ appear to the right (similar to how suggestions work on the product table, it’s not there to begin with until you hover) – and you will see at the bottom it will keep a total number of items you have picked, and then once finished click ‘add to list’ and it will add this to the product list for you.

So there you have it, those are the main new enhancements to the Product Catalog for CRM 2015. It seems intimidating at first as there is quite a number of changes but they just need to be broken down as they all don’t have to relate to each other to start with. As always, any questions please leave them in the comments & I’ll do my best to help you.