Monthly Archives: October 2017

Known Issues in V9

I’m not sure I’ve ever seen this kind of comprehensive “known issues” page for the earlier releases of Dynamics 365/CRM, but it’s definitely worth looking at just so you are aware of some of the issues you may run into in V9:

Dynamics 365 Customer Engagement General Availability Readme (Known Issues)

I just tried reproducing a couple of those issues on my trial instance of V9, and, it seems, at least some of them may have been fixed:

  • I was able to create a dynamic marketing list
  • I was able to add a custom view to the account entity

But, for example, a multi-select option set does show up in the edit mode all the time (in the unified interface)

In other words, it’s possible that some of those issues are being worked on/have been fixed.. But, if you run into something that does not look normal, have a look at that page above – it might be a known issue in this first release of V9.

That said, it’s interesting to look at those issues in perspective. Some of them are happening on IPod, others are happening on Android devices, there are issues happening in the Internet Explorer, and there are yet other issues happening in Firefox.. Some of them are happening in Edge/Firefox/IE 11, but, it seems, not in Chrome. Etc etc.. It seems Dynamics has become a bit of a victim of its own success this time around – there are so many environments it has to work in that it’s almost impossible to make it issues-free everywhere. Well, I’d love it to be issues-free, but, it seems, I can understand why it’s not.. yet:)

So, be aware of those known issues, and enjoy 365-ing!




Dynamics 365: Implementing on-save confirmation dialog with Alert.js

We can make some fields required and we can make other fields optional.. But what about all those not so black-and-white situations where the system may still be able to warn the users about some possible inconsistency in the data, but the user should still be able to override that warning?

There are different options we can use to make this work, but one of them would be to display a warning message form the on-save.  That means we would need to do a few things:

  • Add an on-save handler
  • Display a warning message
  • Allow the user to click “ok” or “cancel” in that message
  • If the user clicks “ok”, we should still save the record
  • And we will likely need to disable autosave, at least in that particular OnSave handler


Here is what I ended up with:


And here is what I had to do to get it to work:

Step 1: Download alert.js and install the solution

First, I went to the  alert.js github page ( Alert.js ) and downloaded the solution from there:


Step 2: Add a web resource

Then, I’ve added the following script to a web resource:

var isConfirmed = false;
function onSave(executionObj)
  var eventArgs = executionObj.getEventArgs();
  if(eventArgs.getSaveMode() == 70)//AUTOSAVE

  var condition = Xrm.Page.getAttribute("name").getValue() == "123";//If not “123”, display a confirmation 
  if(!condition && !isConfirmed)
    eventArgs.preventDefault();"This is not a 123 account", "Are you sure you want to save the changes?", [
         new Alert.Button("Save", confirmCallback, true),
         new Alert.Button("Cancel")  
         ], "WARNING");
    isConfirmed = false;//Reset the flag for the next save

function confirmCallback()
  isConfirmed = true;//to make sure we don't display alert dialog from onSave this time; 

Step 3: Add web resources to the form

After that, I’ve added my new web resource to the form together with the Alert.js web resource:


Step 4: Configure OnSave handler for the form


Step 5: Save, Publish All, and Run a test


That was quick and easy!

But I still wanted to clarify a couple of things call does not block javascript execution. That’s the reason there is a call back function there, and there is a call to Xrm.Page. from that callback.

And I needed that additional isConfirmed boolean variable so the script would not display the confirmation dialog every time.

Happy 365-ing!

Trying Xamarin (with Dynamics, of course.. but not there yet): Broken AVD system path

As far as mobile development is concerned, I’m an absolute newbie at this point.. So, this might be something obvious for those who have been doing mobile development for a while, but, since I have no idea what’s normal what’s not, maybe this post will help somebody else to get things going a little faster.

I kept getting the following error when trying to start an android virtual device:

Starting emulator for AVD ‘MyPhone’
PANIC: Broken AVD system path. Check your ANDROID_SDK_ROOT value [C:\Software\Android\sdk]!


I did some googling, I did some thinking.. I did some cursing, I guess.. none of that was very helpful till I noticed that I had two different SDK folders:



Aha.. From there, it was straightforward. Update ANDROID_SDK_ROOT system variable:


Restart AVD manager, and start the emulator. Back in business we are:


Bug or Feature? System administrators can’t see all forms

For a little while now I’ve been wondering if it’s a bug or if it’s a feature that, at least in the more recent versions of Dynamics, System Administrators won’t be able to choose those entity forms that were not assigned to the “System Administrator” security role?

It seems it was different in 2011, and, maybe, in 2013.. But it’s been a while.

Here is an example. There are 3 main forms in the account entity:


That MoCa form is assigned to the “Field Service – Resource” security role only:


So, even while logged in as a System Administrator, I cannot choose that form:


But, if I add System Administrator role to the form:


I can, now, choose that form when looking at the account record:


This is a bit of a unique situation for System Admins, since, I think, we have access to almost everything else in Dynamics by default (well, another example of where sys admins powers are limited would be personal views/dashboards.. but that makes sense since I probably would not want to see everybody else’s personal views anyway).

Dynamics Tip: Using business rules to sum up more than two fields

When defining a formula in the business rules editor, we can only use two entity fields:


So, what are we supposed to do when we have, for example, four fields to sum up (other than creating a calculated field or adding a javascript/workflow/plugin)?


Turns out, we can simply add multiple actions to the business rule so that every action will add one additional value to the sum field(and the first action will copy value from the first value field):


We also have to remember to add all those value fields to the condition just to make sure the business rule kicks in on all field changes:


And, once we have that, here is the end result:


It works.. Although, I guess it may still be easier to use javascript for thisSmile

Dynamics, Portals, and Adobe

We have a somewhat unique Dynamics environment here in Ottawa, so, sometimes, I am wondering if what’s happening here is a reflection of the overall trend or if it’s all about Microsoft trying to adapt to the specifics of the local market.

You see, most of the Dynamics implementations here are still on 2015 version of Dynamics, and they are still on-prem. This is a government city, so most of those implementations are for the government departments, and, for a number of reasons, they are not able to utilize Dynamics in the cloud yet.

What it means, for example, is that, right now, there is a clear upgrade path for Dynamics.. but there is, essentially, no upgrade path for the portals. Imagine a government department implementing an ADX 7 portal. A few years from now, they’ll go to Dynamics 2016/365/V9.. whatever the version is going to be. However, what are they going to use as a portal solution?

The interesting part is that there is, actually, a portal solution that’s being promoted by Microsoft locally. To me what’s being offered here looks like this:


ADX7 is not an option for new implementations – that’s why it’s pretty much greyed out.

One-Time source code release and community edition versions might be an option BUT they will have to be supported somehow.. and there is no support from Microsoft. Which will certainly make it an issue. So those two options are greyed out as well (may be a little less greyed out).

Then, there are customer portals online. Those are fully supported by Microsoft, but only for the online version of Dynamics. Technically, right now that’s, mostly, not an option because of what I wrote above. It may be an option in the future.

And, then, there is Adobe Experience Manager that’s offering integration with Dynamics (and other sources), and that’s likely a much more powerful product than ADX at this point. So, the relative scale on that image probably reflects the capabilities of those two solutions as well.

Actually, this is not a product of my imagination – this whole post is simply a reflection on the presentation Microsoft hosted earlier today for the government employees/consultants/partners where we saw what Adobe Experience Manager is capable of. I have to say it looked pretty good, though, as usual, the devil should be in the details we have not, really, seen.

Either way, keeping in mind the partnership between Adobe and Microsoft (have a look here, for example), and keeping in mind the announced depreciation of the Dynamics marketing service, I am wondering if we all should get to know Adobe Experience Manager better..

What do you think?

Dynamics 365 (Online): Deleting a user account – what NOT to do

Here is a scenario that may look rather innocent but that may cause a problem that will likely turn into a support call with Microsoft should it happen.

One day, you decide to delete a user account that used to be assigned a Dynamics license:


And, then, the time comes when you need to create a user with the same full name again. Maybe because there is a different user with exactly the same full name.. maybe it’s the original user who has come back..

So, you create another user and grant that user access to Dynamics:


Before long, you will realize that you created a bit of a havoc in Dynamics because, you see, now you have two users with the same name there:


Of course, one of those users is enabled, and another one is disabled. But we are talking about Dynamics 365 Online, so there is no way to update user names for the users directly in Dynamics. And, since one of those users does not even exist in Office 365 anymore, there is no way to update that user’s full name in Dynamics at all!

This does not seem to be such a big issue at the first glance, but think about the data import. Imagine that there is a user lookup field in the entity being imported:


If you try importing that kind of file, you will get an error message because.. there is a duplicate:


Import functionality in Dynamics does not care if those references are active or not, so it won’t be that easy to get rid of this error, especially keeping in mind that, again, you can’t even change user names for the users that have been deleted from Office 365.

That’s when you may need to contact Microsoft support.. Or, if you keep this issue in mind the next time you decide to delete a user from Office 365(admittedly, it might not be that easy to keep this in mind), you might simply rename that user first, ensure that user’s full name has been updated in Dynamics, and, then, delete that user account from Office 365 safely.

Happy 365-ing!

Dynamics 365 (V9): Progress Indicator API

It has only been a few weeks since I wrote a blog post about Alert.js, but, with the release of V9, we now have the same sort of functionality available out of the box:


As described in the “What’s new for developers” article, there have been some client API enhancements in V9.  In particular, we’ve got two new functions in the Xrm.Utility namespace:

  • showProgressIndicator
  • closeProgressIndicator


You can see how the progress indicator looks like above, and here is the code I used to make it work:

function getPrimaryContactEmail()
    Xrm.Utility.showProgressIndicator("Loading contact email..");
    setTimeout(delayedLoadPrimaryContact, 3000);

function delayedLoadPrimaryContact()
    var contact = Xrm.Page.getAttribute("primarycontactid").getValue();
    if(contact == null){
    Xrm.WebApi.retrieveRecord("contact", contact[0].id, "$select=emailaddress1")
    .then(function(result) {
        var email = result["emailaddress1"];
        alert("Here is the email: "+email);
    .fail(function(error) {
        var message = error.message;
        alert("Error: "+message);


That’s a web resource I added to the account form, and, then, I added getPrimaryContactEmail as an onload event handler.

You may be wondering why there is setTimeout in this code.. it’s, really, just to make sure that progress indicator shows up for at least a few seconds. Retrieving contact email from CRM does not take long enough to notice the indicator otherwise.

That’s an oversimplified example, of course.. but, every now and then, we might need this ability to display a progress indicator to notify Dynamics users that something is happening behind the scene – it might be a ribbon button making a javascript call that is supposed to do some extensive server-side processing. Or it might be a javascript calling  a custom action. Or it might be any other javascript that’s taking at least a few seconds to complete.

Hope you are enjoying V9 so far!

PS. And, by the way, if you are wondering about that Xrm.WebApi.retrieveRecord call.. That’s another addition to the Xrm namespace, but you can read more about it here: Microsoft Dynamics 365 v9.0: Usage of new OOB WebApi functions – Part 1

Business rules and read-only forms

There is an interesting limitation of the business rules for which there seem to be no other workaround but to use javascript. Imagine the following situation:

  • There is a user who has read-only access to the account record through the security roles
  • There is a business rule that unlocks a field on the account form

In theory, since the user has read-only access, when such a user opens that record in Dynamics, all the controls on the form should be read-only no matter what.

That’s not the case in Dynamics 365 (V9), though, and, it seems, has not been the case in the earlier versions. You can see it on the screenshot below:

  • The form is readonly
  • But I can still select a value into the Parent Account field

And the only reason it’s happening is because I have the following business rule:

In other words, where we might think that security-based settings will have precedence over the business rules, it’s, actually, not the case.

But what happens if I select a value into that field? Well, not a lot  – yes, I can select a value. But no, I cannot save the record. There is no “save” button anywhere. However, if I try to navigate from that screen after that, I will get this warning message:

And, then, if I click “Cancel”, I’ll get “Access Denied”. Which is expected, of course, so, in terms of data consistency, there is nothing to worry about. It seems to be purely a user-interface issue.

As a workaround, we can always fall back to javascripts (where we can use getFormType to add required conditions), though that’s not, always, a good solution if you are trying to avoid code-based customizations.

Anyway, if this is something you’d want to see fixed/added to Dynamics, go ahead and upvote the idea:

Happy 365-ing!