D365 JavaScript: Navigating Autocomplete Control and Address Copying Challenges


Microsoft Dynamics 365 (D365) is a powerful platform that allows businesses to manage various aspects of their operations. Leveraging JavaScript in D365 enables developers to enhance user experience and tailor the application to specific needs. In this blog, we’ll delve into a real-world scenario involving D365 JavaScript, where we encounter an intriguing challenge involving an autocomplete control and address copying.

The Challenge:

Imagine you’re customizing a D365 form, and you have a requirement to provide a user-friendly way for users to select a country using an autocomplete control. Additionally, you’re tasked with creating a checkbox that, when selected, copies all fields from Address 1 to Address 2. While implementing this, you encounter an issue: the JavaScript code you’ve used works seamlessly for all fields except the autocomplete control. Let’s explore this challenge further and discuss the solution you devised.

The JavaScript Code:

The JavaScript code you’ve provided attempts to handle the country field’s autocomplete control and the copying of fields from Address 1 to Address 2. While the code successfully copies field values for text fields, the autocomplete control poses a unique problem. This code works fine for copying the text address fields. For the autocomplete control, we have to save and refresh the page to see the updates.


To get around this problem, I added the following code:

try {
  const element = parent.document.querySelector('[data-id="address2_country.fieldControl_container"] .wj-form-control[aria-label="Country"]');

  if (element) {
      element.outerHTML ='<input class="wj-form-control" style="font-weight: 600; color: rgb(0, 0, 0);" aria-label="Country" readonly type="text" value="' + newFieldValue + '">';
} catch (e) {

In this snippet, you use the `setValue` method to set the value of the ‘address2_country’ attribute to `newFieldValue`. Subsequently, you attempt to manipulate the autocomplete control by locating the corresponding element and replacing it with an input element containing the new value.

The Autocomplete Control Challenge:

The issue you’re encountering with the autocomplete control stems from its complex nature. Autocomplete controls in D365 often involve intricate components and interactions that standard text input fields do not exhibit. My approach was to directly manipulating the element’s HTML element.


Working with D365’s JavaScript capabilities can be immensely rewarding, but it can also present unique challenges, as demonstrated by the scenario of the autocomplete control and address copying. While your initial approach exhibited promise, autocomplete controls often require more intricate handling. By refining your strategy and exploring D365’s native methods and community resources, you can conquer this challenge and unlock the full potential of JavaScript customization in D365. Remember, JavaScript in D365 is a powerful tool – with a bit of creativity and perseverance, you can overcome any obstacle it presents.

Writing Dynamics C# Console App With Only Two Dependent Packages

Writing C# code for Dynamics 365 opens up numerous possibilities within the platform. It enables the ability to update data in Dynamics (Dataverse) and facilitates integration scenarios, such as connecting external systems with Dynamics. However, one of the common challenges we encounter is the dependency on the .NET version utilized by Dynamics, which currently mandates .NET 4.6.2 and entails several dependencies. These dependencies can present problems, particularly in larger projects. Surprisingly, even for a simple C# application, the list of dependencies can become quite extensive. To make matters worse, one of the dependencies, Microsoft.IdentityModel.Clients.ActiveDirectory, has been deprecated.

How do we get around so many dependent packages? What if we want to run our code under a newer .NET version like 6.0 or .net core 3.1? The good news is that we now have a great solution called Dataverse Client. The code is available on: GitHub PowerPlatform DataverseServiceClient

What’s really nice is that there are only two dependencies to run a simple console application:


Here is a sample CRUD program that connects to Dynamics 365, then create an account, read the account, update it and then delete it.

using System;
using Microsoft.PowerPlatform.Dataverse.Client;
using Microsoft.Xrm.Sdk;
using Microsoft.Xrm.Sdk.Query;
using Microsoft.Extensions.Configuration;

namespace DataverseClientCRUD
    class Program
        static void Main(string[] args)
            var builder = new ConfigurationBuilder()
                     .AddJsonFile("appsettings.json", true, true);
            IConfiguration config = builder.Build();
            string connectionString = config["ConnectionStrings:MyCRMServer"];
            using var serviceClient = new ServiceClient(connectionString);


        private static void CRUD(ServiceClient serviceClient)
            Console.WriteLine("**** Create ****");
            Entity account = new Entity("account");
            account["name"] = "ABC Corporation";
            account.Id = serviceClient.Create(account);

            Console.WriteLine("**** Read ****");
            Entity readAccount = serviceClient.Retrieve(
                entityName: account.LogicalName,
                id: account.Id,
                columnSet: new ColumnSet("name")
            Console.WriteLine("Retrieved account name: {0}", readAccount["name"]);

            Console.WriteLine("**** Update ****");
            account["name"] = "ABC Corp";

            Console.WriteLine("**** Delete ****");
            serviceClient.Delete(account.LogicalName, account.Id);


Create an appsettings.json file in Visual Studio and set the file to copy to output directory:


  "ConnectionStrings": {
    "MyCRMServer": "AuthType=ClientSecret;Url=https://XXXX.crm.dynamics.com;ClientId=XXXX;ClientSecret=XXXX"

Dynamics 365 Interactive Dashboard Showing Inaccurate Data

Interactive Dashboards in Dynamics 365 are highly valuable and offer crucial business insights into the data. However, I encountered an issue recently where the chart counts did not align with the stream counts. While the dashboard displayed the accurate data on the development server, the production server failed to reflect the correct chart counts in comparison to the stream (Grid on the left side). It’s important to note that the stream did display the correct counts, but the individual chart components did not.

Creating a new interactive dashboard fixed the problem, however I had end-users creating customized filters and I didn’t want to have to train them on how to recreate the filters. 

I decided to create a new solution with just the dashboard component and compare the solutions between the development copy and production copy. My handy Notepad++ compare utility showed me what’s different. Somehow during the deployment to production, the default view was pointing to a different GUID. I repackaged the solution and deployed to production and it started working again. Hopefully this will help others.