Diving into the Product Structure of Microsoft Dynamics CRM 2015 (and meet ET)

In my last vlog I went through Hierarchical Security in Microsoft Dynamics CRM 2015. This time round, I'm doing a deep dive into the new Product Structure in CRM 2015. This was my biggest learning curve for Microsoft Dynamics CRM 2015. The processes you have to go through is very different from CRM 2013 and earlier versions. You have to understand the steps in creating certain records to ensure your Product Structure is set up correctly.

Where do I go to create a Product? How do I create a Product relationship and where? Why do I need to create a Product Family? These are all revealed in this vlog post.

I couldn't afford to cut information out in this detailed walk through. If you don't have the time available right now to watch my vlog, try watch it when you do have time as it will help you understand the Product Hierarchy in CRM 2015.

Outline of the different components

Product

• A Product is the item/unit you are selling. This is the base level of the Product Hierachy.
• You can create a Product within a Product Family or Product Bundle.
• You can create the Products prior to creating a Product Bundle.
• Products still use the same set up from earlier versions of CRM where a Unit and Price List is required.

How do I know I'm in the Product?

Product Bundle

• A Product Bundle allows you to sell multiple products together.
• When you create a Product Bundle, the Product Bundle becomes a Product linked to a Price List.
• You need to make sure your Product Bundle is created from the correct Product Family that will be the Parent.

How do I know I'm in the Product Bundle?

Product Family

• A Product Family is where you can group your Products and Product Bundles. 
• You can create a Parent Family with zero products initially.
• After you create a Product, Product Bundle, or a Product Family within a certain Product Family, that Product Family becomes the Parent Family. 

How do I know I'm in the Product Family?

Product Properties

• In the Product Family you can set up the Product Properties. Product Properties are the variances, things like size, colour, texture etc.
• Properties are added at the Product Family level in Draft or Revision state.
• Child Products, Product Bundles and Product Families inherit from Product Properties from the Parent Family.
• Can override Product Properties of child Products, Product Bundles and Product Families.
• Child families can have their own Product Properties in addition to inherited ones.

How do I know I'm in the Product Property?

Activate Product Family

To apply the Product Family in Opportunities, Quotes, Orders and Invoices, make sure you Publish the Parent Family. The top of the Product hierarchy has to be Published first before any Child Product Families can be published. Otherwise an error will be thrown (refer to my vlog).

Product Relationship

Product Relationship allows a Product or Product Bundle to be linked to other Products that can be suggested to the end user for the purpose of upselling, cross-selling, providing a substitute or accessories.

How do I know I'm in the Product Relationship?

Have a Price List default for an end user

You can automatically default Prices List’s based on the Territory record associated to the CRM end user profile.
The Price List entity has a Sub-Grid with the Connections Entity as the source.

Icons

The following are the icons to help distinguish the differences in the Products entity view.

How-to scenarios

OK so I've put together some scenarios and the end user process in CRM for these scenarios.
1. How to create Products
- I want to create a stand-alone Product
- I want to create a Product within a Product Family
- I want to create a Product Bundle within a Product Family
2. How to create Product Properties
3. How to create Product Relationships
4. How to default a Price List for an end user

The assumption is the Price List and Units have been set up, I am not covering this in these scenarios as this is not new functionality.

1. How to create Products

- I want to create a stand-alone Product

The steps are
a) Create Product from Products View by clicking on “Add Product.”

b) Create Price List Items

- I want to create a Product within a Product Family

The steps are
a) Select Product Family record from Product View.
b) Click on “Add Product.”

c) Enter relevant details and Save Product.
d) Create Price List Items.

- I want to create a Product Bundle within a Product Family

The steps are
a) Select Product Family from the Product View.
b) Click on “Add Bundle.”

c) Add the Products you want in the Product Bundle.
d) Create Price List Items.

This following is the sample Product Structure I have applied in my vlog post.

2. How to create Product Properties

The steps are
a) Open the Product Family record.
b) Click on the "+" icon of the Product Properties sub-grid.

c) Enter the relevant details.

Click here for more information on the different fields in the Product Properties record.

3. How to create Product Relationships

I want to suggest a cross-sell of a Product only from one particular Product.

a) Open the Product or Product Bundle.
b) Click on “+” Icon.

c) Selected related Product.
d) Set the Sales Relationship Type to Cross-selling.
e) Set the Direction to Uni-Directional.

My tip for Product Relationships

When you click on the Lookup, it might not be easily deciphered what records on the list are Products or Product Bundles by looking at the icon. I found it easier to add the Product Structure field as a column to the Product Lookup View.

The following is the sample Product Relationship I have applied in my vlog post.

4. How to default a Price List for an end user

a) Open the Price List.
b) Refer to the Territory Relationships tab and click on the “+” icon.

c) Either type the Territory Name
Or click on “Search For More Records.” [bug which I explain later]
Click on “Look Up More Records.”
d) Select a Territory.

Only assign a Territory to ONE PRICE LIST. If you assign a Territory to more than one price list, CRM will not apply the price list automatically to an Order, Invoice or Quote as CRM does not know which price list to apply. Don't confuse CRM.

Things you need to be aware of

Product Family

You can't later select a different parent product family for the child products, bundles or families.

Product Properties

• Can only be configured in the Product Family.
• Different prices for each property cannot be set. So if you want to price a Green Bag as $100 and Blue Bag as $200 based on the Product Property, it won't work using Product Properties. You have to create them as two separate Products.
• Opportunities, Quotes, Order and Invoices display the Properties, you can't use it in a custom entity. 
• Properties not displayed in Advanced Find.

Product Relationship

In my vlog post I could not figure out why I wasn't able to see the cross-sell relationship from the Adult Gym Membership product to the Towel Apparel Merchandise Product. This is because the Price List Item I originally created for the Towel Product was associated to the "Retail" Price List. The Order I used in my vlog post was using the "Retail Membership" Price List. Therefore the Adult Product was not displaying the suggestions of cross-selling the Towel Product due to the Price List Item being associated to the "Retail" Price List. As soon as I created a Price List Item associated to the "Retail Membership" Price List, I was then able to see the suggestion of selling the Towel Product in the Order.

So if you create a Product Bundle and any associated Product does not have a Price List Item associated to the Price List linked to the Order, Invoice or Quote, it will not show as a suggestion.

Summary

Products in Microsoft Dynamics CRM 2015 took me a while to understand and from my vlog post, you can see I slipped up when I wanted to show you how to create a Product Relationship by going to the Product Family. I had forgotten I needed to do it as the Product level.

So to help with your learning in understanding and remembering how things work in Microsoft Dynamics CRM 2015, I have conjured up a magic triangle which I have called "ET," Elaiza's Triangle. Ta da!

The following is outlined in ET:

• Product Families are at the top of the hierarchy
• Products and Product Bundles are underneath Product Families
• Product Properties are created at the Product Family level and is inherited by Products and Product Bundles
• Product Relationships are created at the Product and Product Bundle area

For further information on the Product Structure, refer to the Microsoft Customer Centre.

Thank you for watching and reading this long post. I have shared my knowledge with you and I hope you have a better understanding of the Product Structure in CRM 2015. Awesome sauce!

Toodles.

Read More

Exploring the Hierarchical Security model in CRM 2015

I kicked off the new working year by starting on a new Microsoft Dynamics CRM 2015 project. I've been learning about the new features and in this vlog I am covering the new Hierarchical Security model. This is based on what I have discovered so far and I'll probably learn more about it as I work in other CRM 2015 projects so keep an eye for future related vlog's.

Trial and error over the past few years have made me understand what is easy and difficult to achieve with Business Units, Security Roles, Field Security Profiles and Access Teams in Microsoft Dynamics CRM. One of these scenarios is accounting for visibility of records from a certain level without giving too much access. For example, I am a Membership Director and I'd like to see what is happening with the Membership Reps but I don't need to update information on these Memberships. But I do need to edit the Quotes for Corporate Memberships that the Corporate Membership Manager is responsible for. The concept of Hierarchical Security accommodates this scenario which is explained in my walkthrough.

Righto, here's my thoughts in writing if you couldn't understand what I was presenting.

The following is the layout of a Membership team/department.

I have just used the standard security Sales Person and Sales Manager role where the Read Privilege is enabled to User access only (refer to my vlog). This is for the purpose of demonstrating how Hierarchical Security can be used when combined with security role where User access is enabled as the Read Privilege.

Manager Hierarchy
Manager Hierarchy is for an end user that has directly associated end users to have the ability to create, read, edit, append and appendto access of records owned by the associated end users. For example, I am a Retail Membership Manager and I have the access to any end user who I am a manager of. The Retail Membership Manager can edit the membership records owned by the Retail Reps as the Retail Manager is the direct manager of these individuals.

It can also provide a manager in a higher level to have read access to the end user records that are not associated directly to the manager, AS LONG AS there is another user who is the manager of these end user records and who is also directly reporting to the manager in the higher level. For example, the Membership Director has the ability to see the records owned by the Retail and Corporate Reps but the Membership Director canont edit these records. The Membership Director can see these records because the Membership Reps report to the Membership Manager who directly reports to the Membership Director.

Position Hierarchy
Next up is Position Hierarchy. This one took me a while to get my head around but I think I now get it. You can associate end users to a position which can give them access to records within the same "ancestor path." It uses the parent-child concept.

End Users in a higher position will only have read access of records owned by end users that do not report to their position AS LONG AS these end users is associated to an end user that is in a child position directly linked to the higher position.

During this exploration I found out the following:

• an end user can only have one manager (applies to manager hierarchy)
• an end user can only have one position (applies to position hierarchy)
• you can have many child positions associated to one parent position (applies to position hierarchy)
• an end user from another business unit can be added to a parent position if they need to create, edit, append and appendto access to records at that level (applies to position hierarchy)
• the highest position does not need a parent position, but all lower positions require a parent position otherwise records aren't visible to end users in a higher position. I know this sounds like the obvious but it wasn't for me as I was used to modelling with Security Roles. It took me a long time to workout why I wasn't able to see lower level records (applies to position hierarchy)
• a position can have many end users that are associated to different Business Units. For example the Membership Managers position can have two end users where one end user is linked to the Membership Business Unit and the other end user is linked to the Marketing Business Unit
• an entity view such as Open Memberships will display the records, there is no need to add a criteria to show records where Owner is equal to XXXXX. This was previously required to see records owned by a Team or a new custom view was required to see records based on the access team an end user is linked to (if access teams is used).
• audit history recognizes if a change has been made by a user that has been enabled for hierarchical security
• the dashboards and advanced find also will display records owned by other users that are direct or in-direct reports to the user that has been enabled for hierarchical security.

The one odd thing I found was that if "Organisation" access was enabled in the Read privilege for an entity (eg. Opportunity) the hierarchical security did not apply. Any user that had the manager or position hiearchy enabled could only Read records when he/she was meant to have read, edit append and appendto access. I'm not sure whether this is a bug but this is what I discovered.

This was a learning curve but I'm glad I went through it because now I'm thinking twice about how to structure end users. I have a better understanding of Hiearchical Security modelling in Microsoft Dynamics CRM and I'm sure I'll learn more when combining the other methods of security. I hope you learnt something from me and hopefully this will get you thinking on how to structure end users in Microsoft Dynamics CRM 2015.

Toodles!

Read More