Help(ing you) in Deciding Microsoft Dynamics CRM 2015 Custom Help Implementation

Last couple of weeks ago myself and Elaiza Benitez are collaborating in writing up some posts for the new custom help feature introduced in Dynamics CRM 2015: Help(ing you) in Microsoft Dynamics CRM 2015 with Microsoft Word and Help(ing you) in Microsoft Dynamics CRM 2015 using Office 365 and Microsoft SharePoint online. In the previous posts we mentioned the ways to implement custom help in Dynamics CRM 2015. Custom help is really important aspect in user adoption where the end users (who use the system) can find a guidance on how they will work with the system without the need to contact the trainers or support help desk to solve their lack of knowledge, especially when the organisation just rolled-out a brand new CRM system.

So, in this post I will share my thought on how we could compare the approach and get which one as the best fit to the situation. The first part that drives the decision is whether we would like to implement the custom help globally or per-entity based. Now let’s compare the pros and cons of each implementation and I will give my thought on what would be the typical scenario where the approach will be suitable/applicable.


Global Custom Help

Global custom help is applied system wide, regardless whether an entity is system entity (out of the box) or custom entity, when this functionality is enabled every time the user clicks on the help icon, they will see the custom help instead of the standard out of the box Dynamics CRM help page. Global custom help option might works the best with the next option (Append parameters to URL) so that the help site can redirect or point to the right resource. One of the sample of the implementation with minimum amount of code is covered by Scott Durow in this post. Now below is the analysis on the implementation:

Typical usage for:

  • Organisation wide implementation that has lots of custom entities and renamed most of the system entities, with minor or no 3rd party solutions involved.
  • Requires a centralised location to manage the help content (SharePoint for example).
  • Works well for an implementation where you have high level ownership of the system.

Pros compared to entity-based custom help:

  • Centralised location of help settings (system-wide settings).
  • Easier to maintain the content (will always be in the same location, depends on your routing/pointing logic).
  • Depends on the implementation, non-solution aware help might be helpful if you want to give different help content to a different instances.

Cons compared to entity-based custom help:

  • Not solution aware, needs a bit of admin task to make sure each CRM environment has pointed to the right help content.
  • You could not pick and choose on which entity that you would like to implement the custom help, which leads to the need to provide the content for each entities that you have in CRM (more work to be taken care of).
  • In alignment with the above point, you need to make the help content for each new custom entity created.

Entity-Based Custom Help

Entity-based custom help is applied on per entity basis. So you could specify on which entity the custom help will be applied. In implementing entity based custom help there are many options available, such as using CRM web resource, external web CMS/SharePoint or any other web pages that available to your users (intranet/public site).

Typical usage for:

  • ISV vendors to point the help content to your website knowledge article.
  • Small implementation that has minor customisation.

Pros compared to global custom help:

  • Solution aware, no changes required wherever the solution is deployed.
  • Tailored for each entity, no need to route the help to the specific topic/entity.
  • Have the flexibility to implement only to certain entity (ability to pick and choose).

Cons compared to entity-based custom help:

  • Need to configure the custom help on each entities that you would like to have the custom help (with greater flexibility there is more responsibility).
  • The help content can be scattered all over the place (e.g: help content for entity A is in SharePoint, however the content for entity B is in web resource).

Mixed Approach

You could mix the usage of global and entity-based custom help. The behaviour is the Entity-Based custom help will win. Example: You provide the global custom to (so the user know how to use search engine 🙂 ) and specified the custom help for contact entity to your SharePoint page. So, when users click to open the help on other entity for contact, they will see And when they open the help page on contact, they will see the SharePoint page.

This behaviour is useful when you would like to have a default location for custom help, but for certain entity the help will be given specifically. This is in accordance with ISV mindset that their content will be displayed wherever their solution are deployed.


I hope my thought can help-ing you in deciding the custom help implementation, please feel free to comment and add some ideas/feedback 🙂

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s