Dynamics 365 System Fields Challenge: Disabling the Owner Field with JavaScript

When working with Dynamics 365, most custom fields behave exactly as you’d expect. For instance, if you want to disable a custom field on a form, a simple call like this works seamlessly:

formContext.getControl("custom_fieldname").setDisabled(true);

However, when it comes to system fields like the Owner field (ownerid) you might run into unexpected behavior. In this post, we’ll explore why this happens and how to work around it.

The Issue with System Fields

Dynamics 365 uses system fields such as ownerid to manage essential data (in this case, the record owner). Unlike most custom fields, system fields like ownerid often appear in multiple places on a form. For example, the Owner field can be displayed both in the main form body and in the header. This duplication means that the standard approach of retrieving a control with:

formContext.getControl("ownerid").setDisabled(false);

…can fail or only affect one instance of the control. In our case, you might see an error such as:

TypeError: Cannot read properties of null (reading 'setDisabled')

This error occurs because Dynamics 365 isn’t returning a single control reference for ownerid—or it’s returning null for one of the instances—making it necessary to handle these controls differently.

The Workaround: Iterating Over All Controls

The solution is to retrieve the attribute rather than a single control, then iterate over all associated controls. Each instance of the control can be accessed via the attribute’s controls collection. Here’s how you can do it:

formContext.getAttribute("ownerid").controls.forEach(function (ctrl) {
    ctrl.setDisabled(false);
});

Breaking It Down

  1. Retrieve the Attribute:

    • formContext.getAttribute("ownerid") fetches the attribute object, which represents the data for the Owner field across all form instances.

  2. Access All Controls:

    • Every control bound to the ownerid attribute is stored in the controls collection. This collection might include the header control, the body control, or any other instance present on the form.

  3. Iterate and Disable:

    • Using the forEach loop, we iterate through each control in the collection and call setDisabled(false) on it. This ensures that no matter where the Owner field appears on the form, it is enabled or disabled as intended.

Conclusion

Dynamics 365 provides robust capabilities for customizing forms, but system fields like Owner come with their own set of quirks. While custom fields handle setDisabled without issue, system fields might require you to iterate over multiple controls due to their multi-instance rendering on a form.

By retrieving the attribute and iterating over its controls, you can ensure that all instances of a system field like ownerid are properly updated, leading to a more consistent and error-free user experience. Understanding these nuances not only helps in solving current issues but also empowers you to better manage other system fields in Dynamics 365.

Microsoft Bing Maps Discontinued Services

Introduction
On May 21, 2024, Microsoft announced the deprecation of several key features and services within Bing Maps (Link),  signaling a new direction for organizations relying on these tools for geospatial needs. As many businesses and developers have depended on Bing Maps for location-based services, it is crucial to understand what’s changing, how it affects your workflows, and the recommended alternatives.

The article states that “Customers with an enterprise license have until June 30, 2028, to transition to Azure Maps, while customers on the free and basic license for Bing Maps for Enterprise have until June 30, 2025”.

In this post, we’ll explore the discontinued Bing Maps services, the rationale behind these changes, and how Azure Maps is now the go-to solution for all your geospatial needs.

What is Changing?
Microsoft has released a comprehensive list of Bing Maps services that are being phased out. These services have been essential for many organizations, offering functionalities such as geocoding, routing, traffic data, and more. The main services being deprecated include:

  • Bing Maps REST Services
  • Bing Maps SOAP Services
  • Bing Maps Web Control 6.3

These services have powered numerous location-based applications, but with evolving technology standards and performance expectations, Microsoft is retiring them to make way for newer, more robust solutions.

Why Is Microsoft Making These Changes?
Microsoft’s decision to discontinue these services is driven by a focus on modernization and a shift toward cloud-native solutions. Older technologies like the Bing Maps SOAP Services and Web Control have become outdated, with newer tools offering better performance, security, and integration capabilities.

This change also reflects broader trends in the industry, with cloud-based services becoming more dominant, offering better scalability, real-time data processing, and higher levels of security.

Azure Maps: The New Standard
As Microsoft phases out Bing Maps, Azure Maps emerges as the recommended and supported geospatial service. Built on the Azure cloud platform, Azure Maps offers a comprehensive suite of mapping and location-based services designed to meet modern business needs.

Steps to Transition to Azure Maps

Audit Your Bing Maps Integrations: Conduct a thorough audit of all the places where Bing Maps services are used in your business workflows and applications.
Plan Your Migration to Azure Maps: Azure Maps provides a robust set of services that can easily replace deprecated Bing Maps functionalities. Begin planning the migration process, including which APIs to replace and any necessary redeployment efforts.
Leverage Azure Resources: Microsoft offers a wide range of tools, documentation, and support to help businesses transition from Bing Maps to Azure Maps smoothly. Utilize these resources to minimize migration friction.
Test and Optimize: Once you’ve integrated Azure Maps, ensure comprehensive testing is carried out to optimize performance, validate security, and ensure a seamless user experience.

Conclusion
The deprecation of Bing Maps services is a reminder of how rapidly technology evolves and the importance of staying ahead of these changes. With Azure Maps now positioned as the recommended service, businesses can continue to deliver exceptional geospatial experiences while benefiting from the modern, cloud-native infrastructure of Azure.

By transitioning to Azure Maps, businesses can unlock powerful new features, ensure better scalability, and provide their customers with enhanced mapping services. Now is the time to future-proof your operations by embracing Azure Maps as the new standard in geospatial solutions.

Missing Competitor Field in Dynamics 365 Opportunity: Debugging the “Close as Lost” Button

In a recent project involving Dynamics 365 for Sales, I encountered a peculiar issue where the “Close as Lost” button on an opportunity didn’t show the Competitor field, which is usually expected when accessing the close dialog. There were no custom plugins or workflow assemblies that could have contributed to this problem. So, I embarked on a journey to debug the issue, ultimately uncovering some hidden configuration that caused this behavior.

Problem Description

The typical “Close as Lost” dialog in Dynamics 365 provides a field to specify the competitor who won the deal. However, in this particular instance, the competitor field was conspicuously absent (as shown in the image below. This was confusing because no customizations should have interfered with this standard feature.

Initial Investigations

After verifying that no unusual plugins or workflows were active, I decided to dive deeper into the client-side logic. I inspected the JavaScript behind the “Close as Lost” button to see if there were any parameters or conditions being set that would hide the competitor field. I came across a crucial piece of code that read a specific parameter controlling whether the competitor field would be displayed or not.

Here’s a snippet from the code:

if (ClientUtility.DataUtil.isNullOrUndefined(hideCompetitorFieldAttribute)) {
   hideCompetitorField = hideCompetitorFieldAttribute.getValue();
}

This code was checking if the competitor field should be hidden, and in this case, it was set to “true.”

The Hidden Culprit: An Extra Boolean Parameter

Finally, I stumbled upon the root cause when reviewing the ribbon configuration in Ribbon Workbench. As it turns out, the “Close as Lost” button had an extra Boolean parameter configured by a previous consultant. This Boolean parameter was set to true, effectively hiding the competitor field.

This additional Boolean parameter was unnecessary and had inadvertently caused the competitor field to be hidden during the closure process. Once this parameter was removed or set to false, the competitor field reappeared as expected in the “Close as Lost” dialog.

Resolution Steps

Using Ribbon Workbench, I found an unnecessary Boolean parameter that had been added to the button’s configuration.
Fix: I updated the configuration by either removing the Boolean parameter or setting its value to false.


Conclusion

This issue highlights the importance of double-checking even the smallest customizations in Dynamics 365. A minor oversight, like an extra Boolean parameter, can have significant effects on user experience and business processes. Always ensure that customizations are documented and reviewed, especially when they affect standard features like opportunity closure.

Have you ever encountered a similar issue with missing fields in Dynamics 365? Share your experience in the comments below!

Overcoming FetchXML Limitations: Calculating “Newer-Than-X-Days” with Microsoft Formula Columns

Introduction:

In the realm of Dynamics 365 and FetchXML queries, users often find themselves grappling with limitations, especially when it comes to date filtering. A date filter allowing the display of records “newer” than 90 days from today is currently unavailable. The absence of a straightforward “newer-than-x-days” option in FetchXML has led many to seek alternative solutions. Fortunately, developers like Jonas Rapp and Mark Carrington have proposed workarounds that involve leveraging outer-join functionalities. However, these methods may not simple to implement by end-users. 

The Calculated Field Conundrum: 

Attempting to create a calculated field to bridge the gap presents its own set of challenges. The error message, “This operation cannot be performed on values which are of different Date Time Behaviors,” is a roadblock, particularly when dealing with “Date Only” fields like “Estimated Close Date.” This limitation can be frustrating, hindering the seamless execution of desired date calculations.

A Glimmer of Hope: Microsoft Formula Columns: 

Enter Microsoft formula columns, this alternative method provides a way to perform date calculations without running into the Date Time Behavior mismatch issue. By employing a straightforward formula, users can effortlessly calculate the number of days in the future from the current date.

The Solution: DateDiff Function:

The key to overcoming the FetchXML limitations lies in the DateDiff function provided by Microsoft formula columns. By utilizing this function, users can perform date calculations efficiently. Let’s take a look at a simple example:

DateDiff(UTCToday(), 'Estimated Close Date')

This formula calculates the difference in days between the current date (UTCToday()) and the value in the “Estimated Close Date” field. By using this approach, you can easily filter records based on a “newer-than-x-days” criterion.

Conclusion: 

While FetchXML may present certain limitations, the innovative use of Microsoft formula columns provides a robust solution to the challenge of date filtering. By embracing these alternative methods, users can enhance their Dynamics 365 experience and gain more flexibility in managing and querying data. So, the next time you find yourself grappling with date-related queries, remember the power of Microsoft formula columns to streamline your processes and make your Dynamics 365 journey smoother.

Revolutionizing Business Efficiency: Migrating from a “Broken” On-Premise CRM to Dynamics 365 in the Cloud

Introduction

In the fast-paced world of modern business, digital transformation is the key to staying competitive and relevant. An essential component of this transformation involves transitioning from outdated on-premise systems, such as traditional Customer Relationship Management (CRM) software, to advanced cloud-based solutions. This article explores the journey of migrating from a “broken” CRM system hosted on-premise to Microsoft Dynamics 365 in the cloud. Additionally, it emphasizes the critical role of strategy mapping to ensure alignment between the end system and business processes.

The Legacy of On-Premise Systems

Once considered groundbreaking, legacy on-premise CRM systems often turn into operational hindrances for various reasons:

  1. Maintenance and Upgrades: Maintaining and upgrading legacy systems comes with high costs and disruptions.
  2. Scalability Constraints: Expanding or downsizing an on-premise system is complex and time-intensive, hindering agility.
  3. Accessibility Limitations: On-premise systems restrict accessibility, inhibiting remote work and real-time collaboration.
  4. Integration Complexities: Integrating outdated systems with newer applications can be intricate and costly.
  5. Security Vulnerabilities: Aging systems are susceptible to security breaches and data vulnerabilities.

Elevating Business with Dynamics 365 in the Cloud

Migration to Microsoft Dynamics 365 in the cloud presents a multitude of advantages to address these challenges:

  1. Operational Costs: Cloud-based solutions eliminate upfront hardware investments and ongoing maintenance costs.
  2. Scalability and Flexibility: Dynamics 365 on the cloud adapts resources to demand, ensuring optimal performance.
  3. Remote Accessibility: Cloud platforms enable anytime, anywhere access, fostering remote work and bolstering productivity.
  4. Streamlined Integration: Dynamics 365 offers seamless integration capabilities, connecting with other applications effortlessly.
  5. Robust Security: Microsoft’s cloud services provide robust security features, including encryption and regular updates.

Strategy Mapping: Fusing Technology with Business Ambitions

A triumphant migration to Dynamics 365 hinges on more than just technological decisions. Strategy mapping is pivotal to ensure that the new CRM system aligns with business processes and objectives.

  1. Process Assessment: Before migration, analyze existing processes to identify pain points and opportunities for enhancement.
  2. Clear Goals: Define the CRM migration’s objectives—be it enhancing customer engagement, optimizing sales procedures, or refining data analytics.
  3. Stakeholder Involvement: Engage key stakeholders from various departments to shape the new system according to their needs.
  4. Customized Adaptations: Tailor Dynamics 365 to match your organization’s workflows, accommodating specific processes.
  5. Change Management: Prepare employees for the transition through training and communication about the system’s benefits. Address concerns for smooth adoption.
  6. Continuous Refinement: Regularly evaluate the system’s performance against objectives post-migration. Make necessary adjustments to maintain alignment with business goals.

Conclusion

Transitioning from a “broken” on-premise CRM system to Microsoft Dynamics 365 in the cloud is a strategic move that can rejuvenate business operations. The benefits of cost-effectiveness, scalability, accessibility, integration, and security are compelling reasons to embrace this transformation. Yet, the key to success lies in meticulous strategy mapping that ensures Dynamics 365 aligns seamlessly with business processes and ambitions. By intertwining technological innovation with a comprehensive business strategy, organizations can realize a seamless and impactful digital transformation.

D365 JavaScript: Navigating Autocomplete Control and Address Copying Challenges

Introduction:

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.

formContext.getAttribute('address2_country').setValue(newFieldValue);

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) {
  console.log(e.message);
}

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.

Conclusion:

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:

DataverseCRUD.cs

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);

            CRUD(serviceClient);
        }

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

            //Read
            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"]);

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

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

appsettings.json

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"
  }
}

A big thanks to Marius Pothmann for his blog post: Access Dataverse Web API from .NET Core with Microsoft.PowerPlatform.Dataverse.Client

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.

Dynamics 365 WebAPI Asynchronous Calls

Column Editing Text Editor Editing Dynamics 365 development is a constantly evolving field, with the JavaScript API being no exception. Exciting advancements have been made in this space, such as the introduction of WebApi’s method, which allows for basic CRUD operations (Link).

Gone are the days of worrying about including JSON files or calling jQuery libraries just to make simple API calls. The platform now provides straightforward methods for performing basic CRUD operations.

To illustrate this, here’s a simple example. I utilized the fantastic REST Builder tool to generate the code. This code searches for an email address and retrieves the full name of the corresponding contact record.

function FindContactRecord(email) {
    Xrm.WebApi.online.retrieveMultipleRecords("contact", "?$select=fullname&$filter=(emailaddress1 eq '" + email + "')&$top=1").then(
        function success(results) {
            var result = results.entities[0];
            var fullname = result["fullname"];
            ProcessData(fullname);
        },
        function (error) {
            console.log(error.message);
        }
    );
}

The above code works great for a single record, since the ProcessData function gets invoked in the success function of the WebAPI call. When we start to do bulk operations, the code starts executing asynchronously. Here is an example of calling the function multiple times. This code is only for illustrations purposes. If we were to query multiple contact records, our best practice is to batch multiple email addresses into a single WebAPI call.

function FindContactRecords(EmailArray) {
    var contactFullnames = new Array();
    for (var i = 0; i < EmailArray.length; i++) {
        contactFullnames.push(FindContactRecord(email[i].trim()));
    }
    return contactFullnames;
}

function FindContactRecord(email) {
    Xrm.WebApi.online.retrieveMultipleRecords("contact", "?$select=fullname&$filter=(emailaddress1 eq '" + email + "')&$top=1").then(
        function success(results) {
            var result = results.entities[0];
            var fullname = result["fullname"];
            return (fullname);
        },
        function (error) {
            console.log(error.message);
        }
    );
}

//Main function 
var contactFullnames = FindContactRecords(EmailArray);
ProcessData(contactFullnames);

The main issue we face with the above code is that the contactFullname array will not return elements since JavaScript engine is executing the WebAPI calls asynchronously for performance reasons.

So how do we fix this problem? By using async, await and then statements, JavaScript will return a promise which will not execute subsequent code until the async code completes processing. The changes in blue illustrates the required changes.

async function FindContactRecords(EmailArray){
    var contactFullnames = new Array();
    for (var i = 0; i < EmailArray.length; i++) {
       await contactFullnames.push(FindContactRecord(email[i].trim()));
    }
    return contactFullnames;
}

async function FindContactRecord(email) {
    await Xrm.WebApi.online.retrieveMultipleRecords("contact", "?$select=fullname&$filter=(emailaddress1 eq '" + email + "')&$top=1").then(
        function success(results) {
            var result = results.entities[0];
            var fullname = result["fullname"];
            return (fullname);
        },
        function (error) {
            console.log(error.message);
        }
    );
}

//Main function 
FindContactRecords(EmailArray).then(
    contactFullnames => ProcessData(contactFullnames)
);

There are many articles that discusses async/await, but how to applies to Dynamics 365 is not something well covered. I hope this  article helps.