Blog, Development, Troubleshooting

Html Webresource, Classic UI vs UCI – story of broken functionality

This morning started for me from bug I found really interesting. Product (custom visualization of data we did using Html/JS webresource developed for customer) didn’t work as it should on the UCI. The same time everything worked fine on the Classic UI Client. My investigation led to scary fact – OOB Api (even in your custom Html webresource) behaves differently depending on the type of UI it was invoked from.

Here are settings of the webresource in configuration:

As you can see I configured webresource to pass contextual information (like record id, record type, e.t.c.) and custom parameter (data) inside and parameters are being parsed by page during load. Here is the code that is used for the parsing:

Here is how this “contextParameters” looks like depending on the type of client:

Here is the answer why code that worked fine in Classic UI doesn’t in UCI – custom “data” parameter is not being parsed, type of entity is parsed to entityType instead of typename. To get that resolved and work in both interfaces I had to replace OOB method with own parsing:

UPDATE: after chats with other developers and Microsoftees I was pointed to the fact that getQueryStringParameter method is marked as deprecated and not present in the list of methods of execution context so can’t be considered as supported. Also I ask to consider this post not like criticism of D365CE product group and D365CE product but as a heads up for developers who relied on method used in their Html/JS-webresources.


  1. Had a similar experience with partylists in the UCI. In Web Client you can do:

    let partyRequired = Xrm.Page.getAttribute(“requiredattendees”);
    let attendees = partyRequired.getValue();

    if(attendees[x].type == 1){ //Account


    In UCI .type is not available and throws error. Instead have to use:

    attendees[x].entityType == “account”

  2. True, have similar issue. In USD (just a resource in a tab) this is even the third story. Btw even for the legacy web we had different experience in some cases.

  3. Hi Andrew, Thanks for the share. The MB200 study material even includes an error with this, and I’ve found a few other forums running into the same problem. I wrote a blog post detailing a simple fix to their example regex, and have referenced your article for those who wish to dive deeper, as you have taken a different approach. Thank you!

    MB400 Study Material:

    The Helpful Bit – Check Regex When Passing Parameters:

  4. This problem just tripped me up and your post really helped, thanks.
    You can also do this to parse the query string now with JS:

    var parameters = new URLSearchParams(;
    var customparams = parameters.get(“data”);

  5. As a developer on CRM your posts and answers on the net are usually the most helpful! Thank you so much. I encounter similar problem and your post, as usual, helped me. G-d bless you.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.