I’ve been using apps with Dynamics 365 for some time now and they are a great way of simplifying the user interface in a way that doesn’t require you to cross reference low level security permissions with Site Map XML.

One problem that has come up time and time again is the fact that different organisations often have different types of contact because of the nature of their business. There are a lot of benefits you get from using the system contact entity, which means that creating a new custom entity for a new contact type does not always make sense.

For example, consider an organisation with multiple types of service and therefore multiple different types of customers. They have contacts which may encompass the following types, and contacts may often be one or more types of these.

• Staff Member
• Applicant
• Student
• Citizen
• Farmers

Ultimately, these people are, and should be, contacts in the CRM data model – if we model them as standalone custom entities they are no longer activity parties, they can’t be associated with the customer lookup fields – for example the dedicated customer field on the case record. Additionally, we want to have a single view of the customers contact with the organisation which can be viewed on the activity pane or activity associated view on the contact record.

For this reason, it often seems natural when designing a solution to apply a type field to the contact record. This could be a single option set on the contact record if the contact types are mutually exclusive, or a set of Boolean fields so that a contact can be of multiple types. For example, a staff member could also be a student who works as a part-time farmer (not uncommon in Northern Ireland!).

However, if we model these as contacts in CRM, it is important to consider the user experience when navigating through CRM screens. When a user clicks on the contact menu item on the site map, they could be presented with a list of views where they can view a list of contacts by type – For example, all active Applicants, All Active students etc.

But to improve this, what if we could add multiple entries in the site map to take you directly to a view of each type of contact. This would make the users life easier.

Consider this use case, which demonstrates a non-streamlined user experience with minimal customisations.

1. User wants to view a list of all Students
2. User Clicks on Sitemap
3. User Clicks on Contacts
4. A list of contacts is displayed, but the view is not the Students one.
5. User changes view to Student
6. User clicks into a record
7. User realises that form being displayed does not show Student specific information
8. User browses forms for that contact entity and selects (perhaps guesses) the most appropriate one.
9. Student form is displayed.

The best user experience here is (arguably):

1. User wants to view a list of all Students
2. User Clicks on sitemap
3. User Clicks on Students
4. User clicks into a record
5. The most appropriate form for that student is displayed.

However, even if we know what the most appropriate form is for a particular record, we are limited technically in setting the form based on the value of a field on a record. The default form displayed for a record is the one that was last saved by the user. It can be changed using JavaScript when the form is loaded, but that would involve a page refresh straight after the record is opened (ugh), and that is quite confusing to the user.

So, what is the optimal, supported way of navigating this scenario at using Dynamics 365? (I am using v8.2 here, am hopeful of v9.0 SDK improvements)

Consider this flow:

1. User wants to view a list of all Students
2. User clicks on sitemap
3. User clicks on Students
4. A list of students is displayed
5. User Clicks into a record
6. If form is not optimal for that record, the system prompts the user that record is a student, and suggests the most appropriate form(s).
7. User clicks single button to bring the user to the suggested form.

This scenario can be achieved relatively easily using Dynamics 365 Apps, URL Addressable forms and some supported JavaScript on the contact form. Configuring this pattern will look something like this:

Configure the Site Map and App

• Create appropriate fields on the contact record to segment your contact into different types.
• Create a new system view filtering for each type as required.
• Get the GUIDs for each of the views you have just created. One way of doing this is to navigate to the view and select ‘Email a Link of Current View’. The viewid will be at the end of the URL between the escaped %7b indicator and %7d curly bracket tags.
• Create a new Dynamics app and add the contact record to it. Select all the views you have created that you want to display in your app.
• Open the Site Map within your app and add the Contact record first.
• Now add a subarea of type URL for each of the other types of contact you want to display on the site map in their own right.
  • The URL should be in the format /_root/homepage.aspx?etc=2&viewid={VIEWGUIDGOESHERE}
  • Note : When adding this link in the app designer, it is not escaped as indicated in the MSDN documentation. Paste it in exactly as above or it won’t work.
  • As a side note – you cannot change the sitemap icons for these contact types, even though you have added it as a URL. CRM still appears to parse the entity type code (ETC) or entity type name (ETN) provided in the URL which unfortunately means that the default contact icon will still display.
• Save and publish your app once you have added all your views.

Streamline the form experience.

At this point, you have a set of entries on your sitemap which link directly to the views for each contact type. However, what happens when you click on the record – it will take you into whatever form you last looked at. To improve this experience, you will need to add some JavaScript to each form onLoad event to display an appropriate recommendation to the user. My library of choice to do this is Notify.js, which will give you a nice notification as shown below when you are opening a form.

If you think this type of scenario should be handled better within Dynamics 365 natively, please vote for the submissions below on ideas.dynamics.com for a) this to be handled within the app designer and b) for better URL addressable forms. I’m sure Microsoft can come up with a better way of doing this.

• https://ideas.dynamics.com/ideas/dynamics-crm/782910
• https://ideas.dynamics.com/ideas/dynamics-crm/ID0002065

I should mention, this approach flies in the face of what a ‘Contact’ is the CRM Community Schema project which is a great initiative that takes a different approach to modelling entities. The question is, are you a pragmatist or a purist?