It’s easy right? you just simply go into the solution within CRM, drag and drop navigation elements set the target entity and it’s all done in a jiffy – unfortunately no! Microsoft can you please have a think about how you could make this easier given it is part of the platform configuration? 

This article is going to assume that you don’t really get any kind of buzz from manually editing the Sitemap.XML file or any XML file for that matter and would rather use an interface to get the job done; otherwise if that’s not you then read the following to your hearts content and best of luck! Editing Dynamics CRM Sitemap.


“Doing this manually requires exporting an unmanaged solution, unzipping and editing the files directly before then uploading back to server and importing. This is prone to error and will be more time consuming.”


For all us other people that like to keep things simple we can use XRMToolbox (if you haven’t heard of it read my other article – How to setup a Dynamics CRM Development Environment ) to get the job done nice and quickly I mean it really shouldn’t be that difficult right? So without further a do let’s get on with it.

The Dynamics CRM Sitemap

Ok I will try to move quickly on the history lesson but depending on what version of Dynamics CRM you are working on at the moment the sitemap has evolved with each and every version, originally in CRM Dynamics 2011 we had “vertical”navigation it was truly beautiful (!?!) it looks like this:


Then Microsoft recognised that the Dynamics CRM interface was actually quite uninspring and ugly, it needed a major face lift, fast forward and this is what we have now within CRM Dynamics 2016. In my view the interface is about 100,000,000 miles ahead of Salesforce CRM (SFDC – which seems to be stuck in the early 90’s!).



As you can the navigation is now horizontal at the top of the application where in my view you would expect it to be in the first place (err Website sitemaps tend to be here! not always but mostly…). We access the sitemap via the Hamburger Icon (an internal Microsoft development team expression – don’t ask) which causes the main modules to be displayed to the user, by default:

  • Sales
  • Service
  • Marketing

Along with Settings and Help Center (previously called Resource Center), so in total you have five high level Areas that all fall under the one root node which is the Sitemap itself.

When would it be appropriate to customise the Sitemap?

Glad you asked when you are working with clients not all of them wish to use all of the core features that the platform offers. Public Sector organisations for example, are for more likely to be interested in Service than they are about Sales pipelines, opportunities, leads and such like (though times are changing in the UK Government!). A retail organisation on the other hand will focus on both Sales and Service, plus in most cases Marketing. By customising the sitemap we are able to make the interface much more intuitive and specific to the users of the client organisation. Not only does this improve productivity it will also go a long way to simplify the user training sessions and prevent users from accidentally doing stuff that isn’t helpful.I think projects would run far more smoothly if we could just take away People (joking – but seriously KISS).

Using XRMToolbox to Edit CRM Dynamics Sitemaps

The Sitemap plugin within XRMToolbox, is not “solution aware” neither is that required as sitemap customisation always edits the master underlying system sitemap extension.

Although, solutions can have the sitemap extension included within them they are all in effect referencing the same default sitemap on that instance. Therefore “the order” in which you install 3rd party managed solutions is likely to impact on the sitemap and command button layout too if those solutions have included the Sitemap or Application Ribbon components (under Client extensions) within them.This isn’t just true for sitemaps it is pretty much the standard in terms of how solutions are layered upon each other. A common misconception is that a Dynamics CRM Managed Solution can be “gracefully” uninstalled well don’t fall for that Microsoft sales/ISV nonsense!!, in reality, even managed solutions are directly updating the default (system) solution this means that even if a managed solution is uninstalled there will still be fragments of meta-data left behind which does and can cause problems between solution updates! Apologies I digress this is a subject for another article but just be mindful of it.

Here is the little Gem we need!


When you open it up for the first time it will look like the following, note you need to first connect to your target CRM Instance then click the Load SiteMap button.

xrm interface.png

So we can see that out of the box (OOB) Microsoft Dynamics CRM 2016 Update 1 has five main areas.We can modify the existing Area’s and create new Custom Areas as required, you would create a custom area if you had a number of custom entities all providing extended functionality that are best grouped together; alternatively depending on the nature of the application you may instead to include those entities as part of a Group within the existing OOB areas. In the end, it all comes down to ensuring the UX makes sense for how CRM is being utilised by your client or employer.

So what is an Area?

An area is what you see along the vertical navigation, each one will then have one or many “Groups”, think of Groups as being the vertical lists of entities that each in turn have a header whenever you click on the area (tile icon). In turn each group then has sub areas and these are the actual links which could be an entity or a view. A good example is the settings node, which has five groups and then within each group, the sub areas which are the actual links

Example: Editing the Account item under the customer service area/group

sales links.png

The above diagram hopefully illustrates the correlation between links shown in the CRM application and where those settings are located within the XRMToolbox Sitemap editor.

Publishing Changes

Normally it isn’t needed to do a “Publish All Customisations “to see changes, a forced refresh of the default home page normally will cause the sitemap to refresh in the browser (you may have to do a couple of refreshes first).


Adding New AreasItems

If you right click on each of the nodes within the Tree:

  • SiteMap
    • Area
      • Group

The context menu will have a very useful option labelled “Add default X” this is a major time saver! So check that out and the same approach is used for adding custom entities.

Most of the time we are just want to use the standard OOB entities and move things around to better suit the client that is using CRM.

Custom Entities on the Sitemap

When you create a new custom entity it will be added to the sitemap under an “Extensions” group which isn’t normally what we want. Very often, custom entities need to be promoted (moved) to specific Area’s and/or groups as part of the main navigation.

Remember however that even if the sitemap has been correctly customised to show “entity x”, it will not be shown unless the user also has a security role that enables them to see it. Therefore, we start off with a standard “sitemap” but in reality, it will look very different across users depending on their security role(s) within the system.

High Level Steps

Typically the process is as follows:

  1. Load XRMToolBox
  2. Setup and/or connect to target CRM instance
  3. Load SiteMap Editor plugin
  4. Click LoadSiteMap
  5. Right click on sitemap node and decide whether to add a default or create new area
  6. Click Save (top right) under Properties pane
  7. Click Update Sitemap
  8. In CRM go to main page and force refresh (may take couple of attempts for cache to reload)

 Other Considerations

  • Ensure consistent naming convention with area, group and sub area ID’s
  • You will most likely want to create transparent web resources (GIF’s) for Areas and if you haven’t already the custom entities
  • To not confuse user experience try to avoid changing out of the box icons/behaviours
  • Decide whether to add Privilege to sub-area to help control visibility or leave to system
  • If you have requirement for different languages the tool may be restrictive