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.
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:
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.
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.
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
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.
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.
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.
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.
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.
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.
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:
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.