Every developer that has worked with Dynamics CRM knows, or at least (s)he should, that client side javascript customizations are a valuable addition to get that little bit of extra out of the standard Dynamics CRM package.

I myself have learned to appreciate javascript more by doing just that. Extending the standard functionalities of Dynamics CRM.

If you want to do more than some little cosmetic changes on a form, you can create your own webpages and use them in Dynamics CRM by inserting them as a WebResource. Keep in mind that you can only use HTML webpages to host in Dynamics CRM and they cannot execute server side code. You can reference other WebResources by creating a folder structure in the naming of your WebResources.
More information on that can be found on the MSDN  website.

So yeah, hosting an Angular SPA in Dynamics CRM, it’s possible.

If you don’t want to use any Dynamics CRM data in your Angular SPA, why host one in Dynamics CRM. So I started a simple CRUD application by using the fantastic XrmServiceToolkit library . There even is a Typescript definition file in the wild for that library. So I was good to go, or so I thought.

While the XrmServiceToolkit works great and is useable inside Angular, it relies on callback functions for asynchronous functionalities and has no support for promises. Which is a valid approach, don’t get me wrong, but I wanted those promises.

And so my focus changed from a simple Angular SPA inside Dynamics CRM with some CRUD executions to developing a reusable toolkit based on the XrmServiceToolkit and an Angular SPA that executes each of the SOAP and REST functions that I converted.

I called it the ngXrmServiceToolkit and it exposes the same SOAP and REST methods as the original, minus the SOAP grantAccess, modifyAccess, revokeAccess and retrievePrincipalAccess. Let’s call those work in progress.

So what is available:

• When accessing the Dynamics CRM SOAP endpoint:
  • createEntity
  • retrieveEntity
  • updateEntity
  • deleteEntity
  • execute
  • fetch
  • retrieveMultiple
  • queryByAttribute
  • queryAllByAttribute
  • setState
  • associate
  • disassociate
  • assign
  • getCurrentUserId
  • getCUrrentUserBusinessUnitId
  • getCurrentUserRoles
  • isCurrentUserInRole
  • retrieveAllEntitiesMetadata
  • retrieveEntityMetadata
  • retrieveAttributeMetadata

• When accessing the Dynamics CRM REST endpoint:
  • createRecord
  • retrieveRecord
  • updateRecord
  • deleteRecord
  • retrieveMultipleRecords
  • associateRecord
  • disassociateRecord

The result of my work is hosted on GitHub .

It includes the source code for the reusable Angular factories I created, a demo project created in visual studio and a managed Dynamics CRM solution that is the WebResource representation of the demo project.

This is the demo web page inside Dynamics CRM:

I made the Index-page the configuration page of the Solution. So all functionalities can be tested without touching anything else but the solution.

No custom entities or fields are being used. Both the SOAP and REST test actions can create (and update/retrieve/delete/…) an account and a contact. If you leave the configuration section of the solution without deleting the created test records, they will persist in your environment.

All actions are hardcoded, so there is little to no user input in the demo. It was just easier to create the demo that way.

How does the demo application work?

As there are 2 factories available, one for SOAP actions and one for REST actions, the demo application is divided into 2 sections to demo the available actions.

Each section has a set of dropdown buttons with actions connected to it.

There are test entities available in the angular controller and their JSON representation is shown on the page.

The result of each action is shown with a popup, or in the Fetch Result section or a combination of both.

A separate section is provided for the metadata actions.

Some actions cannot be executed in certain situation. E.g.: update account cannot be executed before the account has been created. The application will notify you with a popup message when that is the case.

Feel free to leave your thoughts, questions, issues about this demo or the toolkit in the comment section of this blog post, or directly in the GitHub repo.

The provided sample solutions worked like a charm. Time to implement it in my real world scenario. The documentation on the MSDN sample page clearly states that the label values in the xml are solely there for readability purposes. They are NOT used in the script.

Well, I don’t like typing too much, so when creating my own xml, I left out each and any label attributes.

Imagine my surprise when I used this on my form and the result of the dependent option sets looked like this:

At first I thought I made a mistake and started going through my xml. Except for having no label attributes whatsoever, the file was ok. That’s when the developer in me started going through the actual code. And surely, while the sample documentation states that the label values are not used. They are …

Luckily, there’s just a little bit of extra code needed to make this work as promised.

These steps are necessary to make this work:

1. During the initialize stage, get a hold of the original option set values of the dependent option sets. They will be in the correct language, provided that translations are in place in your environment.
2. When creating the options array for each parent item, get the label from the original option set value that we retrieved in step 1.
3. In the interest of readability, write a separate function to do the search necessary in step 2.

The code before the change:

The code after the change:

I left the option to set a label value provided in the xml, just in case the translated text is not found. Which for me would result in null labels again, but hey, I will configure this correctly so it won’t be needed, right?

The result after changing the script:

A downloadable version of the full improved javascript file can be found here .

This concludes this blog post, hope it helps!

The outlook client itself has undergone some changes, but those are not in the scope of this blogpost. You can read about it here.

After installing the new outlook client, and starting the configuration wizard, the following error message popped-up:

Searching the internet for this error message, a lot of possible causes for getting this error showed up. What eventually pointed me in the right direction was this article on the Microsoft support site.

The instructions are easy enough and the explanation is clear. But after following them, I did not find an issue in my sitemap. I actually went through the xml of the sitemap several times before I saw the problem.

I recreated the issue in a demo environment where I created a sitemap that looks like this:

As you can see, there are multiple areas which in turn contain some groups which contain the subareas. In the sitemap documentation, it is stated that the subareaid should be UNIQUE. Looking at this xml, you can clearly see that the same id is used for multiple subareas.

CRM itself does NOT complain about this, proven by the following image:

So at first I thought this couldn’t be the issue. As you can see that every path to a subarea with id nav_accts is unique. Simplified in a tree it looks like this:

• Area Id=SFA
  • Group Id=Customers
    • SubArea Id=nav_accts
  • Group Id=SFA
    • SubArea Id=nav_accts
• Area Id=CS
  • Group Id=Customers
    • SubArea Id=nav_accts

But for the outlook client, every subareaid should be unique within the AREA that it resides in, REGARDLESS of the groups. I did not find this little quirk documented anywhere.

And sure enough, after modifying the id of one of the subareas in the SFA area, I could go through the configuration wizard without issues.

The result in outlook:

This concludes this blog post, hope it helps!