As I prepare for my MB2-716 exam I’m producing a series of blog posts that collectively should help others revising for the MB2-716 Certification. (Microsoft Dynamics 365 customization and Configuration.) This time I will look at Option Sets.

Option sets are simply pick lists. The value that is stored in the database is actually an integer but in the entity definition we relate each number to a text label. The text label shows as an option name on Dynamics 365 forms, views etc. As an example I have created an option set. I’ve added it to a custom entity I use to hold “policies”. My option set is called policy type and holds values like “Car”, “Home” etc.

Below you can see the field definition for this field from my policy entity.

• Data Type, option set!
• Use Existing Option Set, in this first example I have said no. This means the list of options is specific to this entity, this type of option set is known as a local option set. (I will describe how this option can make use of global option sets later in this post.)
• Default Value, in my example I have set this to car, meaning new policies would default to being for car insurance. (You can leave this set to “Unassigned Value” if you don’t wish to define a default.)
• Options, I created the list of options by pressing the green “+” button.
  • On the right had side I entered a label for each option.
  • The value field will default but you can change it if required.
  • For the default publisher all values will start at 100,000,000 but other publishers can default to different ranges. This helps to identify who added what options.
  • The description and color fields are optional.
  • Having added the options, I can use the arrows to manually change the sort order. Or the A-Z icons can be used to sort alphabetically.

Global Option Sets

If I expect to re-use an option set that it can be created as a global option set. This gives several advantages;

• Re-using the options sets is more efficient as it saves the time of repeatedly entering lists.
• If an option is added or changed, making the change once will affect all occurrences of that list in the system.
• Reporting is consistent across the multiple entities the use the options.
• Mapping of global option sets does not present any issues with data inconsistency. (See notes below on mappings!)

To create a global option set, I create it as before. But this time I answered “Yes” to the use existing option set question. If your option set already exists, you can simply pick it at this stage. But the first time you need it you’ll select the “New” option. You can then proceed to create the list.

Tip: Global options sets also appear in your solution under the heading of option sets. You can also create them from there if required.

After creating a global option set you can use the edit button to add new options or change existing ones. These changes would apply to all the occurrences of the global option set.

You do need to be mindful of deletions! (On local and global option sets.) If the option is currently being used the existing records will not actually be changed. But when you view them they are going to show as blank as the option no longer exists. And you won’t be able to use Advanced Find to locate them as once deleted you wouldn’t be able to select the old option in your search criteria. Therefore if you do need to delete an option set item it is good practice to update the existing data prior to removal of the option.

Mapping Option Sets

I haven’t covered relationships and mappings yet. So at this point don’t worry about how to create mappings. It is enough to just know that mappings are used to default fields on child entities when created from a parent. You often see this happen in Dynamics 365! For example, when you create a case from an account form the account name is populated onto the case using mappings. Some mappings are part of the system and can’t be changed but often developers will create custom mappings.

I mention this here as there is a specific concern with option sets. Something you will need to be aware of!

What is “special” about option sets is you need to keep in mind that the option set value is mapped not the text. Imagine you map an option set on one entity to another option set. What will happen if the combinations of text and value do not match. To illustrate this, I have shown two option sets below. One as it might appear on my parent entity and one on a child.

If Car Insurance or Life Insurance is selected on the parent, a new child entity would show the same result. As their values match on the parent and child.

But selecting Home Insurance on the parent would show Pension fund on the child! As both have a value 100,000,001 but they have different text values.

Selecting Savings Policy or Pension Fund on the parent would result in nothing being shown on the child. As it is not aware of those options.

Hopefully I have covered most of the key points you need to understand connected with Option Sets for the MB2-716 exam. 

As I prepare for my MB2-716 exam I’m producing a series of blog posts that collectively should help others revising for the MB2-716 Certification. (Microsoft Dynamics 365 customization and Configuration.) This time I will look at calculated fields.

In previous posts I’ve covered entities and fields. This post will build on that knowledge by looking at calculated fields.

A calculated field, as the name suggests, is simply a field which is derived from a calculation. The calculations can include conditions and make use of fields on the current entity and related parent entity. They can work with number fields but also date calculations and string manipulation are possible.

The best way to learn about calculated fields might be to look at an example.

Say I have an entity which contains someone’s salary pretax and in another field I hold the tax amount. I might want to calculate their total salary after deducting tax. Below you can see that I have started off by creating a new field called “Salary (After Tax)”. The field has been set as a currency data type and the field type has been set as calculated. Notice that as soon as the field type is changed to calculated the field requirement option set becomes readonly. This is because calculated fields are not directly entered by the user and therefore have no requirement level.

Next notice that an “Edit” button has appeared next to the field type.

Tip: Something to consider is the data type of the field to be returned. If my calculation is going to work with currency, for example, I will probably need to return the result as a currency. If you try to create a calculated field that returned a text field into a currency field then an error would be given and this would be prevented.

It might be important to know that once you click edit the field is actually created. And that the field type becomes read-only. Because the field type cannot be changed it is therefore not possible to convert simple fields to calculated. (If you wish to do this you’d need to create a new field!) However the formula behind the calculated fikedl can be changed at any point.

I can now use the edit option to define how the field should be calculated. Notice that calculated fields can have conditions but for now I have left these fields blank. I have simply entered the calculation I required. Which is salary – tax. Notice that as I enter my formula I get to pick the field / functions I require from a drop down.

After I accept my calculation not formatting changes to give a clear description of the calculation.

To demonstrate how this will work I have then added my salary, tax and this calculated field to my form.

Once I have saved and published my change I can test it. See below that I have entered a salary of £50,000 and a tax amount of £5,000. The system has then calculated the post-tax salary of £45,000. (Don’t you wish tax values were really this low???)

A couple of things to notice, firstly that the Salary (After Tax) field has a lock symbol. This denotes that it is read-only. Importantly you need to also be aware of when the calculation happens. Calculated fields are set when the record is saved. NOT when the data is entered.

NOTE:
The calculated value is also set when a form is opened or a value viewed in a list view.

This was a simply example, I hope you can already see that conditions could be added. To illustrate how this might work I altered the calculation. Firstly, I made it more complicated by adding an extra deductions field. That I added a condition, which was based on a two option yes/no field. In my example this was to decide if a £10,000 annual bonus should be applied or not. My calculated field now looked like this. I hope this demonstrates how you could start to make the logic a little more complex.

Date Fields

There are a number of functions available with date fields. Some add hours, days, weeks, months or years to date fields.

There are also a set of commands to allow you to subtract from dates.

Tip:
Also notice below NOW(). This will return the current date time. Useful if you want to add or subtract days from the current date!

Meaning, ADDDAYS(2,createdon) would return a date two days after a record was created.

You can also calculate the interval between two date in minutes, hours, days, weeks, months or years.

String Calculations

Calculations are also possible with strings.

Use CONCAT to combine two strings. And TRIMLEFT or TRIMRIGHT to return the start or end of a string.

Including Fields from the Parent

I mentioned in my opening paragraph that you can reference details in the calculated fields from parent entities. To do this in your formulae enter the name of the parent entity and then press “.”, this will present you with a list of fields from the parent entity that can be included in the calculation.

This is actually sometimes useful to show data directly from the parent record on the child record. By way of an example, I have created a text field that contains the account name and city from the parent account on my entity.

On my Dynamics 365 form you can see the result below.

Note:
Changes to the details on the account record do mean this calculated field on the child entity are updated. Meaning this information will stay in step.

Tip:
Another tip is that a calculated field can include other calculated fields!

Hopefully this post has given you the information you need to understand calculated fields in preparation for your MB2-716 certification.

I am using Dynamic 365 Editable SubGrids on the form. However, I have to prevent user from editing some of the fields.

 Is there any out of the box configuration that allows to lock the field in Editable SubGrid like CreatedOn which is by default locked?

Thank You.

As I prepare for my MB2-716 exam I’m producing a series of blog posts that collectively should help others revising for the MB2-716 Certification. (Microsoft Dynamics 365 customization and Configuration.) This time I will look at rollup fields.

In earlier posts I have looked at entities, fields and calculated fields. This post will continue that theme by reviewing the concepts connected with rollup fields.

When I reviewed calculated fields I showed how they could take data from the current entity or its parent. This is very useful but often you will have a requirement to work with information from child records. Imagine you have an entity called “Policy” and that is linked to an account. Each account could have multiple policies. It might be that you need to calculate the total value of all the policies for the account. To do that we’d need a rollup field.

As an example I have created a policy entity, given each policy a value and added that to my account. So on an account I can see the policies and their individual values. Below you can see that I have added a policies sub-grid to my account form.

Next on my account I create a new field that will hold the total policy value. Notice that I have set the field type to “Rollup”. Having saved the field I can then select the edit button to define the logic to rollup the policy value.

The details for rollup field looked like this.

Notice that I have selected my policies entity as the related entity. I then said I want a sum of policy value. (Other options available to me are count, max, min and average.) This is important to remember as roll up fields only work with numeric values. Whereas we saw that calculated values could also work with strings.

In my simple example I left the optional filter section blank. But this can be used to filter record. For example: If some policy values were annual and some were monthly I could decide which to roll up into a monthly total and which into an annual total.

Also commonly in the filtering you might see that we only want to count “active” records. As I might not want to include cancelled or expired policies which would be inactive records.

Tip: Notice the yellow warning which mentions the mass calculate system job.

Tip:Also notice that you can  use the entity hierarchy when creating rollup fields. I explain this here.

Once I have saved my new field I can add it to the form. Creating this one field actually created four fields. Two fields are used to hold the policy value. “Total Policy Value” and “Total Policy Value (Base)” this was because I created a currency data type. All currency fields hold a value in the base and local currency. Although it is often true that these values contain the same value. (When the base currency and local currency are the same!)

It also created last updated on and state fields. These fields are needed as rollup values are not updated real-time, meaning that in some circumstances you will want to know when they were last refreshed. And if it was successful.

Having saved and published my change when I first opened my form it looked like this;

Notice the fields were initially blank. But clicking the refresh icon forces a fresh and they changed to reflect the values shown below.

Note:
If I had waited for 12 hours the fields would have been refreshed with me manually selecting refresh.

Note: There are some limited capabilities with rollup dates. For example you could find the earliest or latest date from a child entity. (Using max / min functions) To illustrate this I have shown a max date on the screen below.

Rollup fields are calculated on demand like this using the refresh button.

When you create a new roll up field a process will run to roll them up 12 hours after the field is created. After that a system job will be fire every hour to keep them up-to-date.

Calculation of a rollup Field is a recurring job. The administrator can change the timing and frequency of the recurring jobs used to roll up fields.

To change the recurrence of a roll up the administrator needs to find the system job for the calculation, opens it and selects the option to modify the reoccurrence. Below you can see that I have opened systems jobs, changed the view to give me all rollup field calculation jobs. I then use the actions menu to display and edit the recurrence.

Note: Rollup fields are not available on many to many (N:N) relationships.

Note: Calculated fields cannot be include in the rollup calculation.

The roll up field has a status; this is general not required but is useful if you get unexpected results. The possible values of the status field are shown below.

Some considerations to be aware of are listed below;

• When you manually refresh a field the maximum number of records considered for rollup is 50,000. If you exceed this when rolling up manually an error will be given. However this limit does not apply when the automated system job is used to calculated the rollup value.
• You can define a maximum of 100 rollup fields for the entire organization
• You can define a maximum of 10 rollup fields per entity.
• A workflow wait condition cannot use a rollup field.
• You cannot rollup a rollup field.
• A rollup cannot reference a calculated field that references another calculated field.
• The rollup can only apply filters to the source entity or related entities simple fields or non-complex calculated fields.
• Rollup fields do not support many to many (N:N) relationships.
• Business rules and workflows always use the last calculated value of the rollup field.
• The rollup happens under the system user context. Meaning all users see the same rollup field value, regardless of security roll.
• If the precision of the aggregated field is greater than the precision of the rollup field, the aggregated field precision is rounded down to the precision of the rollup field, before the aggregation is performed.
• Rollup field aggregation uses only direct relationships explicitly defined in the rollup field definition, no other relationships are considered.

I hope this post has fully explained roll up fields and covered all of the points you need to learn for the MB2-716 exam.


As I prepare for my MB2-716 exam I’m producing a series of blog posts that collectively should help others revising for the MB2-716 Certification. (Microsoft Dynamics 365 customization and Configuration.) This time I will look at field level security.

In previous posts I have already covered the Dynamics 365 security model. I began with this post giving an overview of the Dynamics 365 security and then I continued with a second post giving a detailed view of the security model. What I’ve covered so far essentially relates to entity level security. But what if you need to control who can see, create and update individual fields within an entity? This is when you’d use field-level security.

Field-level security can be applied to system and custom fields across the system. And by default is disabled for all fields.  Field security works in conjunction with the wider Dynamics 365 security model. Meaning a user would first need to be granted access to the entity. But having been granted that access the field security profile is applied to govern access to specific fields within the entity.

To enable field security on any field you open it in customizations and change the “Field Security” option to disabled.

Once this change is published a key will show next to the field to highlight that it is subject to field security. (As shown below.) At this point only the system administrator can see and maintain the details in this field.

If any user, other than the system administrator, looks at the form they will see “******” in place of the data. (As shown below.)

It is important to realize that field-level security does not apply to just Dynamics 365 forms but everywhere you might see or maintain data. For example, below I have shown a view containing my “Secure Field”. Notice that it is blank, this isn’t because the field contains no data! It is because the current user does not have read privilege on this field.

Below you can see that field security is also applied on editable grids ….

To grant access to fields which are enabled for field-level security you need to create a field security profile. This is done from the “Field Security Profiles” option which can be found in the security area of settings.

When creating a field security profile you first give the profile a name and optionally a description.

Once you have saved the profile you can use the “Field Permissions” option to add whatever level of access is required. You can see below that I have granted read access on my field. But I haven’t granted update or create access.

Tip:
Having just create access might be useful if you want someone to set-up a field when a record is created but then not change it afterwards.

Having created the desired field permissions, you can then assign users or teams to the profile. Below you can see I have assigned this profile to one user.

Tip: A real world scenario assigning teams to the profile might be the best option. As user teams helps to keep administration to a minimum.

Below you can see that after granting read only access the content of the secure field is now visible but the lock icon next to the signifies that it cannot be changed.

As always, I suggest your exam preparation involves plenty of hands-on time. So try creating some field security profiles to see how they operate.

I hope this post has given anyone preparing for the MB2-716 exam the basic information they will need to understand on field-level security.

Hello,

I have a problem with my configuration of the USD. I have followed a training of Neil Parkhurst on Youtube. I configured the USD exactly as he described, but i am getting some errors with my sessions.

When i click on a record from a view, the session opens and the record is been shown, so far so good.

Error1

However, as the record is being opened, a extra screen pops up saying: This page cannot be displayed. The URL of this screen is: http://event/?eventname=usdrawdataload&dataloadstate=1&turboform=true. If i look at the debugger, i can see that there a two problems: with Expander Left Splitter Collapse and Expander Right Panel Collapse. Anybody know how to fix this?

Error2

• The account's name does not show up in the Account Tab, it stays: Account
• The session's name does not change. It stays: New session
• An overview of the account is not being shown

I don't know if the bulletpoints of the second error are caused by the first error. Does anyone have a suggestion on how to fix this?

Thanks a lot!

Best regards,

Arne Bok

I recently needed to configure my USD application to send an email based on a template. Here is how I achieved this.

The situation I faced was that I wanted a toolbar button that would send an email to a customer associated with a case. This email was to contain details of a support case I have found in the knowledge base.

I am going to assume you’re a USD “expert”! By that I mean you already have the required logic to open the case and knowledge base article. In this post I will focus only on how the email template operates.

I will present the logic of using email templates using the example I have mentioned, hopefully you will be able to review and adapt to other purposes.

For my example, I needed five actions, a toolbar button and of course an email template.

I will break this change down into the following steps;

1. Create email template.
2. Create action, clear data parameter.
3. Create action, to get email template.
4. Create action, to open new email.
5. Create action, to inject the template details into the email.
6. Create action, ExecuteOnDataAvailable, to pause.
7. Create toolbar button.

Step One – Create email template

The first step was to create an email template, well I say create. I actually copied this one from the Microsoft USD sample package! The important thing to notice is how I have inserted several USD style replacement parameters into my email template.

Step Two – Create Action, clear data parameter

So why do I need this? I found that my logic could fail it I sent multiple emails within one session. The reason relates to the ExecuteOnDataAvailable action we will see in a second. What I am doing here is clearing any existing data relating to a previous email. I am effectively clearing the stage ready for this new email.

Step Three – Create action, to get email template

The next step is to create an action that will copy the email template details into the context. My action looked like this;

At this point it might be worth considering the result of this action! Having run it we will have copied some details, they show as replacement parameters in USD. These parameters are “under” CRM Global Manager#template, so [[CRM Global Manager#template.description]] etc.

Step Four – Create action, to open new email

Now we need an action to create an email. Mine is shown below, I used a New_CRM_Page action.

Step Five – Create action, to inject the template details into the email

Now we need an action to use the replacement parameters we grabbed from the template. [[CRM Global Manager#template.description]].

NOTE:
When I use these I add +v into them! [[CRM Global Manager#template.description]+v]. The “v” means that we expect the template description to contain replacement parameters of it’s own and they should also be replaced.

But the code below does more than just add the template in the subject and description of the email. I am also setting the “to” field. I could have set the “to” field in my “New_CRM_Page” action, so didn’t I? The reason is connected with entity type. As on the case I have the name of the entity for the customer field. That being “account” or “contact”. But the New_CRM_Page action need the entity number, so 1 for account etc. To get round this I decide to set the “to” field using the code below.

// ** Update the subject and description of the email
Xrm.Page.getAttribute("subject").setValue('[[CRM Global Manager#template.subject]+v]');
Xrm.Page.getAttribute("description").setValue('[[CRM Global Manager#template.description]+v]');

// ** Set the email to be to the "customer", which can be a contact or an account
var toLookupValue = new Array();
toLookupValue[0] = new Object();
toLookupValue[0].id = "{[[incident.customerid.Id]+]}";
toLookupValue[0].name = "[[incident.customerid.name]+]";
toLookupValue[0].entityType = "[[incident.customerid.LogicalName]+]";
var toObject = Xrm.Page.getAttribute("to");
if(toObject != null) {
  toObject.setValue(toLookupValue);
}

Step Six – Create action, ExecuteOnDataAvailable, to pause

The RunXrmCommand I have created needs to be run only once the email page is loaded. I therefore use an ExecuteOnDataAvailable action to wait for this to happen. The value I wait for can be any replacement parameter from the email. So I opted for [[email.Id]].

Once created you will need to add a sub-action to this action! So select sub action calls from the navigation.

Then add the RunXrmCommand action we created earlier to this ExecuteOnDataAvailable action. The result is we are simply saying execute the RunXrmCommand action after waiting for the email to load.

Step Seven – Create toolbar button

The final step is to create a toolbar button and add the actions we’ve created. My toolbar button looked like this ….

I used an image for my toolbar button. It happens to be an email icon that I thought was appropriate. You could use a different image or simply opt to have some button text.

Notice the order of the actions we’ve created. This is significant!

Also notice I have a condition on my button. As I don’t want the button to show until I have selected a knowledge base article and an incident.

In my application the final result looked like this. Clicking on the email icon loaded the email. Populated the “to” and “regarding” fields. Plus filled in the subject line and description of the email. Complete with personalised data based on the information found in the case and knowledge base article.

Hopefully you will have found this post useful. I am confident I will be adding more email templates into my application as they really help to make the agents job easier.

Having trouble deciding which route to go.   I want the VP Sales to only view items that fall under managers that report to the VP.  For example, the default view for "My Team's Open Opportunities" is visible by the direct manager the sales person reports to.  I would like this same data to roll up to the VP.  I can't have the VP see all open opportunities as we have various regions controlled by specific VP's. 

What's the best route to go?  I currently have 3 BU, Top level and 2 sub-levels.  I rather not create BU for ever Branch/Manager, but if I need to then it is what it is.  Thank you 

As I prepare for my MB2-716 exam I’m producing a series of blog posts that collectively should help others revising for the MB2-716 Certification. (Microsoft Dynamics 365 customization and Configuration.) This time I will look at status and status reason transitions.

As you revise it is wise to keep referring back to the skills measured statements to ensure you are fully covering all of the points mentions. In this post I will cover the item underlined red, “status and status reasons”.

Status (aka Statecode)

Every entity has a status field. It governs the main “state” of the record.

Custom entities and many system entities have just two states, active and inactive. Inactive records are read-only and can be activated again if required.

There are some system entities such as lead, opportunity and case that put a slightly different interpretation on the status field. An opportunity, for example, is shown and being open or closed. These system entities may also have more than two states.

It is important to understand that the status field cannot be customized.

Status Reason (aka Statuscode)

For each status multiple status reason options can apply. These are used to give further detail about that status.

For a custom entity we have two default status reasons of active and inactive. These can be renamed.

For both system and custom entities we can change the labels used in status reason or add addition options.

I have shown the status and status reason options for several key system entities below. You can also see a full list for all entities here.

Case

Lead

Opportunity

You can’t customize the status field but you can make changes to the status reason field. Below you can see the status reason for a disqualified lead. It would be quite a common customization to add additional reasons for marking a lead as disqualified.

Status Reason Transitions

You can also define what are the valid transitions for a status reason on an entity.

For example, in my application I can log project issues. An issue is initially logged, then it is reviewed. After a review it is either accepted or rejected. And an accepted issue may be resolved.

In my example you shouldn’t take an issue that has been marked as accepted back to a logged status.

This type of logic can easily be implemented by using status reason transitions. You will find an option called “Edit Status Reason Transitions” in the ribbon bar of the status reason field.

Below you can see that I have enabled status reason transitions and then defined which status reasons can be selected for each of the options.

I hope this post has given the key details needed for preparation for the MB2-716 exam.


Quick question, would one track referrals at the opportunity level or at the account level.  Not sure what best practices are for this.

Thanks!

Until recently I have always only had my toolbars show in very specific areas of my Unified Service Desktop, but what if you’d like a toolbar to appear in the status bar or even floating your second monitor?

Normally when we create a toolbar container its display group might typically be “AboutPanel”, “CtiPanel” or “ToolbarPanel”. You can see in my USD interface below that I have pretty standard toolbars positioned in these commonly used locations.

But what other positions do we have? Maybe you could position a toolbar at the bottom of the screen in your status panel. (So StatusPanel) I quite like this one!

Or how about in the left panel (LeftPanelFill) or right panel (RightPanel).

Or maybe even you’d like a floating toolbar. Possibly one that you could position (automatically) on a second monitor. When you use the FloatingToolPanel location you may wish to resize the window, position on the screen and even move to a second monitor. (More on those things in a second.)

Tip:
FloatingToolPanel and FloatingPanel seem to be interchangeable terms!

I can even position my toolbar in a tab next to my agent scripts! By using the display group “WorkflowPanel”.

Meaning we have the following possible options (and maybe more);

• ToolbarPanel
• CtiPanel
• AboutPanel
• StatusPanel
• LeftPanelFill
• RightPanel
• WorkflowPanel
• FloatingToolPanel (or FloatPanel)

Technically you could also use “MainPanel” but I suspect that might be a little strange!! (In that circumstance, you’d be much better using a navigation toolbar rather than one linked to a toolbar container!)

Below you can see my hosted control for my main toolbar that I show in the ToolbarPanel. So the simplest way to create a toolbar in an alternative location is create a new toolbar and add which ever display group you feel works well.

But we also have a few actions that can be used to help position toolbars.

MoveToPanel

Your toolbar containers will not have a UII Action called MoveToPanel. At least not out of the box. Simply navigate to its UII Actions and add a new action called “MoveToPanel”. You can then create actions to move the location of a toolbar. Or simply run actions directly in the debugger to test the art of the possible! Below you can see me experimenting by moving my “About toolbar” to the status panel.

ReAlignWindow

The ReAlignWindow action might be useful if you use floating panels. For toolbars or anything else for that matter! As with this action I can control which display the panel shows in and its size.

See below that I have used a ReAlignWindow command to set the position and size of my floating toolbar.

Notice that I have given values for screen, top, left, width and height.

Tip:
A word of warning! I found this action works great but depending on your interface you could find the floating panel gets “hidden” behind your main USD screen. You might want to think about that as it could be confusing for the end user.

ShowToolbar / HideToolbar

These actions might be useful! They allow you to hide and show toolbars. Possibly you don’t just want a button to be hidden but everything on a toolbar. In these circumstances this action can help.

Notice that the name I give is the name of a specific toolbar not the toolbar container!

Hopefully you can see the setting toolbar locations is pretty simple. It is just a matter of you experimenting on what works well for you. I hope this has given you some ideas on how to be more creative with the placing of your toolbars.

As I prepare for my MB2-716 exam I’m producing a series of blog posts that collectively should help others revising for the MB2-716 Certification. (Microsoft Dynamics 365 customization and Configuration.) This time I will look at relationships.

A good start point is often to read / re-read the skills measured statement (shown below). In this we can see that we need to understand relationship types, cascading rules, hierarchical data, entity mapping and connections. In this post I will focus on what I consider to be the “core” relationship concepts. Then in future posts I will expand on these to discuss hieratical data and connections.

Overview

Understanding how to relate Dynamics 365 entities to each other is a key concept when you are customizing the system. Within Dynamics 365 there are several ways to create a relationship between two entities and also multiple types of relationship.

The system entities that come preconfigured with Dynamics 365 already contain many relationships but you can create additional relationships between system and custom entities. It is also possible to amend relationships to alter how they behave. As cascading rules define what will happen to child records when the parent is assigned, shared, deleted etc. For example, if we delete an account what will happen to all of the contacts associated to that account?

Relationship types include;

• One to Many (1:N) or Many to One (N:1)
• Many to Many (N:N)
• Hierarchical Relationships (e.g. Account and sub accounts.)
• Connections
• Customer

Exam Tip: There is no such thing as a one to one 1:1 relationship!

Also, linked to relationships we have field mapping rules. These are applied when one record is created from another. For example, if we create a contact from an account the address, phone number and such like for the contact can be defaulted to the details from the account.

One to Many Relationships (1:N)

One to many relationships are the most common type of relationship in any relational database. It is very common for a parent to have one child or multiple children. Examples of a one to many relationship would include an account having multiple contacts. Or a contact having multiple cases.

With a 1 to many relationship, the child record will have a lookup field that contains the GUID of the parent. A contact for example will have a look up to the account entity.

FYI:
GUID stands for global unique identifier, it is essentially a reference that uniquely identifies any record in your Dynamics 365 database.

Let’s look at a very simple example of a 1:N relationship. Below you can see then on my account I have a sub grid of contacts. Meaning each account (1) can have many contacts (N).

The contacts are the children of the account. On a child contact we can see that it has a relationship back to the parent. We see this in Dynamics 365 as a lookup field.

Many to Many Relationships (N:N)

With a many to many relationships the parent can have multiple children and the child can have multiple parents. One example of this might be competitors and opportunities. As there might be multiple competitors on one opportunity. And each competitor can exist on multiple opportunities. In this scenario on the opportunity we’d have a sub grid of competitors and on the competitor we’d have a sub grid of opportunities.

On the opportunity we see a sub-grid of competitors….

Then on the competitor we see a sub grid of opportunities ….

With many to many relationships we have two approaches to implementation. The first is described as a “native many to many” relationships. The link between competitor and opportunity is an example of a “native many to many relationship”. These are created simply using functionality available directly in Dynamics 365.

The second type of many to many relationship is called a “manual many to many” relationship.

Before thinking about a manual many to many it might be worth considering what is happening behind the scenes when you create a “native many to many” relationship. As the system actually creates a hidden entity that acts as an intersection between the two entities. Effectively each entity has a many to one relationship with the intersection. Which in turn effectively creates a many to many relationship. A manual many to many takes the exact same approach expect the intersection is manually created.

Manual many to many relationships are used when additional fields are needed to capture extra detail. Imagine we have an entity called events and another called delegates. Each delegate could attend multiple events and each event would have multiple delegates. But each time a delegate attends an event we might wish to capture some additional details about that booking. Such as any special instructions for dietary requirements, expected time of arrival etc etc.

When creating a “manual many to many” relationship we actually create an intersection entity. (Meaning it isn’t hidden and additional fields can be added.) The intersection entity will contain the GUIDs from both of the related entities plus any additional fields.

Note: You will often see the GUID field described as the Id field, the terms are interchangeable!

Connections

Connections are essentially a special relationship that allows us to link records in a “non-traditional” manner based on a connection role. Traditional relationships are “hard” relationships, such as linking a case to a contact. Connections are useful to record “soft” relationships, such “is a friend of”, “former employee of”, “went to school with” etc etc. Below you can see an example where my contact “Anne Jones” is a former employee of “City Power”, has a child called “John” and a colleague called “Nancy”.

Customer

Microsoft Dynamics CRM 2016 Update 1 introduced the capability to create a customer field on any system or custom entity.

“Customer” has been a special polymorphic relationship. For example, consider the customer field on cases. It is polymorphic because a customer could be an account or contact, so we can have one field that can relate to either entity.

This relationship always existed in older versions of “CRM” but it wasn’t until CRM 2016 Update 1 that customizers could create customer fields on any entity. It is now possible to create a customer field on any entity.

You can find out more about the customer relationship by reading a post I created when this feature was introduced. (CRM 2016 Update 1 – Customer Field)

Creating Relationships – One to Many

I have used the concept of a custom policies entity in previous posts, so I will stick with that as an example of how to create a one to many relationship. Say I want each account to be able to have one or many policies.

First of all, I navigation to the primary entity. In this example that would be account. So I open my solution (or from the default solution using the customizations option) and then find the account entity. Next I select 1:N Relationships and click “New 1-to-Many Relationship”.

I can then define the details for the relationship. As shown below.

The detail of each field is described below. You should study this and in particular ensure you understand the relationship behavior section which describes how cascading rules work.

Relationship Definition

Lookup Field

Navigation Pane Item for Primary Entity

Relationship Behavior

Create Native Many to Many

Creating a native many to many relationship is actually very similar to creating a one to many relationship. Except the many to many relationship does NOT have any cascading rules.

I hope this information will be useful to anyone preparing for the MB2-716 exam. But as always I should stress that you can’t rely on theory alone to pass the exam. Getting hands on experience is also essential.

In future posts I expand on these concepts by discussing entity hierarchical relationships and connections.


Hi ,

I would like to ask about Microsoft Dynamics CRM 2016 Customization and Configuration Exam (MB2-712),

I want to take this exam but I need to prepare for this exam first, so please can you give me any advice before taking this exam, and if you have some resources like books, materials.... etc that can help me, please provide it. :)

Your help in this regard will be highly appreciated!

Thanks,

Best Regard ..

As I prepare for my MB2-716 exam I’m producing a series of blog posts that collectively should help others revising for the MB2-716 Certification. (Microsoft Dynamics 365 customization and Configuration.) This time I will look at hierarchical relationships.

You will see in the skills measured statement, under “Implement entity relationships” that we need to understand how to work with hierarchical data.

What is a Hierarchical Relationship?

A hierarchical relationship is used to reflect how one record in an entity relates to another. A good out of the box example of this might be how accounts can have parent accounts. Allowing us to create an account structure of head office, regional offices and branch offices. You can also create custom hierarchical relationships.

Hierarchical relationships are self-referential one-to-many relationships. (Self-referential as the account has a parent account.)

When a record in CRM is part of a hierarchy you can see this in the list views. As a “hierarchy icon” is displayed next to the record.

Also on the forms for the entity an option will appear to view hierarchy and the “hierarchy icon” will also be present.

Selecting any of these options will give a graphical representation of the hierarchy. An example is shown below. Notice that the hierarchy can have multiple levels as a parent account can in turn have a parent account.

How to Create / Edit a Hierarchical Relationship?

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.

I haven’t covered the concepts associated with forms. (yet!) So I will not discuss the form in detail! 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.

I hope this post will have been an aid to anyone preparing for the MB2-716 exam. But as always I would like to stress that you need to get as much hands on time as possible.


We have a bunch of Articles and we want to use them in the new Interactive Service Hub.  My question(s), would be:

How to transfer these articles to the new Interactive Service Hub?

Is there a better way of getting to the Interactive Service Hub?

Currently the only way I have access to them is from the yellow alert bar that shows up when I'm looking at the Articles.  How can I make this Service Hub a navigation button.  I have seen it on other instances, but not on my own.

Does anyone have any links or documentation on the Interactive Service Hub and how to use?

As I prepare for my MB2-716 exam I’m producing a series of blog posts that collectively should help others revising for the MB2-716 Certification. (Microsoft Dynamics 365 customization and Configuration.) This time I will look at connections.

There are many situations when you want to “link” entities but you don’t want to actually define a “fixed” database relationship. This concept is of particular importance in “CRM” systems when it might be useful to know how our customer base and contacts are related. In traditionally database solutions we define fixed relationships. These denote “facts” that in turn drive functionality in the system. Examples might include a quote relating to an opportunity or products that relate to an invoice.

But what if we want to note that our primary contact on an account is married to the CEO of another company. Or maybe that contact used to work for an organization or has been known to influence purchasing decisions of an “unrelated” account. Connections allow us to create these types of unstructured relationships in Dynamics 365.

Below I have shown how I have connected my contact “Debra Garcia” to several records.

• Her contact record is connected to the account “City Power & Light” as they are her former employer.
• She is connected to “Hammy Hamster” as he is her pet. (!!)
• John Grey is her child.
• And Matt Manchester is her colleague.

Hopefully this demonstrates that connections can be with multiple types of entity and that each one has a role. It is often easy to think of connections in terms of how accounts and contacts relate but keep in mind that any entity can be related to any other entity in this manner.

Hammy Hamster is the pet of Debra! Looking at Hammy’s connections shows us their two sided nature.

As on Hammy’s contact record we can see that Debra is his owner.

Therefore, the role has two sides. Other more “normal” examples might be “Husband and Wife” or “Supplier to and Customer of”.

The concept of noting that someone is a family member, former employee or “whatever” in a CRM system can be really useful. These connections unlike a traditional relationship don’t suggest any physical / transactional relationship but knowing how all of your contacts and accounts are networked together can be very handy.

Enable an Entity for Connections

For an entity to be enabled for connections it will need to have the connections property selected. Many system entities are enabled by default but you may need to enable connections on a custom entity before creating your connection role(s).

You should be aware that once an entity has been enabled for connections this property cannot be disabled.

Connection Roles.

Before we can connect anything we need to define the possible connect roles. Luckily out of the box Dynamics 365 ships with many pre-created connection roles. So often a role will already exist.

To access the connection roles (and create your own) use the connection roles option that can be found in the business management area of settings.

As you can see below many connection roles exist out of the box. Including former employee, former employer, referred by etc etc .

To illustrate how these roles work it is possibly easiest to look at the example I have already given of owner and pet. Below you can see the connection role for owner.

Notice that each role is given a category. Categories include business, family, Social, Sales etc. The category is simply used to group connection roles, it has no other functional purpose.

Having given the role a name and category you will then decide if it should be available on all entities or more commonly you select the entities it applies to. In this example the only entity selected is contact. As only a contact can be an owner of a pet. (An email, case, or campaign are unlikely to have pets!)

Next notice the optional connecting connection role. In this example we want one side of the relationship to be the owner and the other to be the pet. Linking to a second connecting role of “Pet” allows us to achieve this.

If we look at the connecting role of pet you can see that it is also only available on contacts. And in turn that it connects back to the role of owner.

Viewing and Creating Connections

Once the connection exists viewing connections is simply a matter of navigating to connections. You will find a connections option in the navigation area of any entity enabled for connections.

Selecting this option will show a list of existing connections and allow you to maintain them.

Next you can select to connect the entity to you or to connect it to another entity. (Tip, the connections option can also be found in the main ribbon on any form!)

Next you search for the entity you wish to connect to and select a role for the connection.

Optionally you can enter a description specific to this connection. For example, I have commented that Rene and Anne have been friends since school.

In the details section you can also see the matching connection role, if one exists. And also optionally give assign a start and end date. For example, the dates might be useful when connection someone as a former employee as you could say when they were employed.

I hope this post has given you a flavor for the functionality associated with connections that you will need to know for the MB2-716 exam. As always I will stress the importance of getting some hands on experience, so I encourage you to create several connection roles and test out how they work. 

I use the following condition to check a,b values before save.And I call this function form's onsave Event.

if the field values a == b means i need to save the record.Else I need to show the alert.

if a!= b condition the infinite loop will occur which means the alert message shows continuously .My problem is i need to prevent save record if(a!=b) . I used eventArgs.preventDefault(); but its not working.

Am working in CRM 2016. 

function onsavecall()
{
if(a != b)
{
alert("alert a is not equal to b .so please change value B");
}
else
{
Xrm.Page.data.save.then(function(){
Xrm.Page.data.refresh();
});
}
}

Thanks in Advance

As I prepare for my MB2-716 exam I’m producing a series of blog posts that collectively should help others revising for the MB2-716 Certification. (Microsoft Dynamics 365 customization and Configuration.) This time I will look at entity mapping.

Entity mapping is an “extension” to relationships that allows us to map fields. This can be really useful when creating new related records. Consider the process for creating a new contact related to the account. When we do this there are lots of fields that could be usefully defaulted on the new contact. (Including things like phone number and address.)

An important concept with entity mapping is that the mapping only applies when new records are created directly from the parent.

Mapping is NOT designed to keep the fields synchronised it simply defaults them when new records are created. Meaning mapping is never applied on the update of records.

As the fields on the related entity are simply defaulted it does mean that users can edit (or remove) this information before saving. For example, the contacts phone number might usefully be defaulted to match th e account. But sometimes the contact will have a different phone number and this might be changed before saving the contact.

It is possible to map one field on the parent entity to multiple fields on the child entity. To illustrate this I’ve shown how I can map address line 1 on the account to address line 1 of both the shipping address and the bill to address on an order.

It is important to understand that the mapping can only occur when the child record is created directly from the parent. For example, when creating a contact the mapping will only take effect if I first load the account and create the contact from the account form. I have shown this concept below by creating a contact from my account. Notice how the address and phone number fields are pre-populated. This is because they have been defaulted from the values held on my account.

If I have created the contact outside the context of the account this mapping could not and would not have happened.

Data types, when you map a field the data types must match. If you try to try to create an invalid mapping, the error shown below will be displayed.

Take a moment to consider the possible errors mentioned in this error message.

• The data type must match– meaning single line to text to single line of test. Or currency to currency etc.
• The length of the target field cannot be shorter than the source field– meaning you can’t map a text field that is 100 characters long to a field that is 10 long. (But you could map one that is 10 long to one that is 100 long!)
• The format should match– text fields (for example) can have formatting. As they can hold phone numbers, urls, email addresses etc. Any formatting options muct be the same on the source and target fields.
• The target field must not be used in another mapping– We can map one source field to multiple targets. But each target can only exist once.
• The source field must be visible on the entity form– meaning to map phone number from the account to the contact, phone number must show on the account form.
• The target field must be a field a user can enter data into– See note below!
• Address ID values cannot be mapped– you can map individual address fields but you cannot map the address ID field. (An internal GUID used to hold addresses.)

Note :I wanted to review what was implied by the comment “target field must be a field a user can enter data into”. So I did some testing! I thought of three combinations which could come into play here;

1. The field is read-only on the form … in this circumstance the mapping applied and the child record was correctly saved with the field populated.
2. The field is not on the form … in this circumstance the mapping applied and the child record was correct saved with the field populated.
3. The field is restricted using field security profile …. If you map something into a field but you don’t have the security privilege to create that field an error will be given.

Create a Mapping

To create a mapping simply open the parent entity in the customizations area of Dynamics 365. And select the required relationship.

On the relationship you will have the mappings option, use the “New” button to create a mapping.

Having selected “New” you can enter the source and target field information. (Keeping in mind the restrictions on field types (etc) discusses above.

I hope this post has given you a detailed overview of entity mapping in Dynamics 365 and will serve as useful information whilst revising for the MB2-716 exam.

One of my organizations just gives me an error of "Sorry, something went wrong while initializing the app. Please try again, or restart the app" at "4/5 Downloading Customization" when accessing the hub.

I have turned on tracing and I am not sure what even look for in the logs.

Any advice? This issue is only present on some of my organizations. This issue is not present on an empty organization with no customizations.