D365 Product Bundles – max number of products

By default, D365 CE has a limit of 15 Products that can be added to a Product Bundle. When you try to add a 16th you get presented with a nice warning message (above). Fortunately, this is one of the many configurable items of D365. In the System Settings, navigate to the Sales tab and change the Set maximum products in a bundle setting to a higher value.

D365, Flow and Twilio

In this post I will walk through the steps to use Microsoft Flow and Twilio to provide two factor authentication for registering with a Microsoft D365 portal. For the purpose of this post I am not actually going to go through the portal registration process as there are plenty of posts out there on how to configure the D365 portal for registration. Instead, I will simulate the process by creating my own Contact record and using Flow to deal with the messaging.

The first task is to sign up for a Twilio account. The great thing is they provide free trial to check the services are going to meet your needs. For our needs we are creating a Verify project.



The next step is to verify a phone number against your own Twilio account. This option also allows you to set 2FA on your own Twilio account.


We then add a Friendly Name for the application.


Add a phone number to make your first request


Pressing the Make Request button will send the message to the designated mobile number with the Friendly Name of your project in the content of the SMS message. Make sure you select the correct Country Code!


To verify the code supplied in the SMS message you can complete the process by supplying the verification code.


If you supplied the correct verification code then you will get the following response.


Having completed the setup for the Verify project we can now turn our attention to the Microsoft Flow configuration. The process will need to send the verification code when a new Contact record is created that contains a value in the Mobile field.

The first step is to create a trigger that is going to start the operation. For this we need a Dynamics 365 trigger called When a record is created.


Make sure you give your trigger an appropriate name before you add any other actions because this can’t be changed once actions are attached to the trigger.


Enter the name of the D365 Organization and the select the relevant entity for the trigger, in our case its the Contacts entity. After that we add our first Action which is a Condition to check that the Mobile Phone field has a value. If it doesn’t the workflow will just finish.


If a Mobile Phone number is supplied in the new Contact record then we can create the request to our Twilio application. This is done by creating an HTTP Action that uses the POST method to send the request.


Twilio has some good documentation on the API requests that can be made for the Verify API, including simple examples. – Verify Phone Verification API. Using this API we need to provide a couple of header values. The first is normal Content-type (application/json) and the important one is the X-Authy-API-Key which is available in the General Settings of your Verify Project.


The POST body names to contain the key-value pairs for parameters listed in the API documentation. For the phone_number we select the dynamic value from the Contact Mobile Phone field. To test our Flow we can use the Test option and create a quick Contact record in D365.



Once you click the Test button then you need to create your Contact record and fill out the Mobile Phone field. The mobile phone number can be entered without spaces, with spaces or with hyphens.


You should then get a response on your Flow to say that everything ran successfully, plus you should get you SMS on the mobile phone you entered in the Contact record with a verification code.


You can also review the Flow history within the Flow dashboard, under My Flows, to see which requests were successful. Opening the specific run will provide details of when the trigger was fired, which Actions were completed and details about the POST request and response.


In my next post I will provide a walk through of how to verify the code that was supplied in the SMS message.

D365 Authentication – connect my apps

With the constant push to make data more secure D365 now includes Application Users that can be configured to allow access to D365 from external applications. There are numerous articles around explaining how to create your Application User in D365 using Azure AD App Registrations – this one from PowerObjects has a good explanation of steps required to achieve this.

In this post I wanted to briefly describe the next steps for using that authentication method in your app to perform CRUD operations. To demonstrate this I created a simple Console App to connect to a D365 instance and perform some simple operations using both the OrganizationWebProxyClient and the CrmServiceClient. For reference, I added a package from NuGet called Microsoft.CrmSdk.XrmTooling.CoreAssembly which contains the official Microsoft.Xrm.Tooling.Connector assembly. The same NuGet package also contains the Microsoft.CrmSdk.CoreAssemblies dependency which contains the Microsoft.Xrm.Sdk.dll. Within the console app I created a class that manages to authentication.

using Microsoft.IdentityModel.Clients.ActiveDirectory;
using System;
using System.Collections.Generic;

namespace OrgService.Connect
    class AuthHook : Microsoft.Xrm.Tooling.Connector.IOverrideAuthHookWrapper
        // In memory cache of access tokens
        Dictionary<string, AuthenticationResult> accessTokens = new Dictionary<string, Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationResult>();

        public void AddAccessToken(Uri orgUri, Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationResult accessToken)
            // Access tokens can be matched on the hostname,
            // different endpoints in the same organization can use the same access token
            accessTokens[orgUri.Host] = accessToken;

        public string GetAuthToken(Uri connectedUri)
            // Check if you have an access token for this host
            if (accessTokens.ContainsKey(connectedUri.Host) && accessTokens[connectedUri.Host].ExpiresOn > DateTime.Now)
                return accessTokens[connectedUri.Host].AccessToken;
                accessTokens[connectedUri.Host] = GetAccessTokenFromAzureAD(connectedUri);
            return accessTokens[connectedUri.Host].AccessToken;

        private AuthenticationResult GetAccessTokenFromAzureAD(Uri orgUrl)
            string organizationUrl = "https://myD365instance.crm6.dynamics.com";
            string clientId = "00000000-0000-0000-0000-000000000001";    // This is the Application ID from your App Registration
            string appKey = "<the client secret for your app>";          // The Client Secret from your App Registration
            string aadInstance = "https://login.microsoftonline.com/";
            string tenantID = "00000000-0000-0000-0000-000000000001";    // The GUID of your Azure Tenant ID. See the article above for details on finding this value.

            ClientCredential clientcred = new ClientCredential(clientId, appKey);
            AuthenticationContext authenticationContext = new AuthenticationContext(aadInstance + tenantID);
            AuthenticationResult authenticationResult = authenticationContext.AcquireToken(organizationUrl, clientcred);

            accessTokens[new Uri(organizationUrl).Host] = authenticationResult;

            return authenticationResult;

To access the D365 instance using the OrganizationWebProxyClient we can use the following code

                string organizationUrl = "https://myD365instance.crm6.dynamics.com";

                var hook = new AuthHook();

                var requestedToken = hook.GetAuthToken(new Uri(organizationUrl));

                using (var webProxyClient = new OrganizationWebProxyClient(new Uri($"{organizationUrl}/XRMServices/2011/Organization.svc/web"), false))
                    webProxyClient.HeaderToken = requestedToken;

                    // Test with a basic WhoAmI request first
                    OrganizationRequest request1 = new OrganizationRequest()
                        RequestName = "WhoAmI"
                    OrganizationResponse response1 = webProxyClient.Execute(request1);

                    // We are also able to create an instance of the OrganizationService and run queries against it
                    IOrganizationService organizationService = webProxyClient as IOrganizationService;

                    Entity entity = organizationService.Retrieve("account", new Guid("92348762-0D32-E611-80EC-B38A27891203"), new Microsoft.Xrm.Sdk.Query.ColumnSet("name", "preferredcontactmethodcode"));


Using the Microsoft.Xrm.Tooling.Connector we require a slightly different approach when using the authenticated Application User. It still uses the AuthHook class but through the AuthOverrideHook property. This uses the same AuthHook object we created earlier for the OrganizationWebProxyClient.

                // Register the hook with the CrmServiceClient
                CrmServiceClient.AuthOverrideHook = hook;

                // Create a new instance of CrmServiceClient, pass your organization url and make sure useUniqueInstance = true!
                var client = new CrmServiceClient(new Uri(organizationUrl), useUniqueInstance: true);

                // Test with a basic WhoAmI request first
                OrganizationRequest request2 = new OrganizationRequest()
                    RequestName = "WhoAmI"
                OrganizationResponse response2 = client.Execute(request2);

                Entity entity1 = client.Retrieve("account", new Guid("92348762-0D32-E611-80EC-B38A27891203"), new Microsoft.Xrm.Sdk.Query.ColumnSet("name", "preferredcontactmethodcode"));

D365 – Web API – Custom Actions & Entity Reference Inputs

Using v9.0 of the D365 Web Api we are able to trigger Actions. Using a standard URL structure we can call those Actions from client-side script, for example – POST /api/data/v9.0/incidents(00000000-0000-0000-0000-000000000000)/Microsoft.Dynamics.CRM.new_CustomIncidentAction.

When these Actions have Input parameters they can be added to the body of the request but knowing how to structure the body can be a bit of a challenge. For numeric, character and boolean values it’s just a case of constructing the relevant JSON object. For EntityReference’s there is a specific structure which will require you to find some details in the ODataV4Metadata.xml file. This file can be downloaded by going to your D365 instance under Settings | Customizations | Developer Resources and clicking on the Download OData Metadata link under the Instance Web API section. Search the file for the name of your Action you want to call and you should get something similar to this…

<Action Name="new_CustomIncidentAction" IsBound="true">
<Parameter Name="entity" Type="mscrm.incident" Nullable="false" />
<Parameter Name="TeamId" Type="mscrm.team" Nullable="false" />

The first is the GUID of the incident we are running the Action against. The second is the one we are interested in as this is our input EntityReference.

To construct the JSON body of our request we need three pieces of information

  1. Parameter name – this we can get from the XML (above). The name is case sensitive.
  2. The OData type – this is also specified in the XML, but needs to be defined in a slightly different format than is defined in the XML.
  3. The EntityReference Id – the GUID value for the entity

The JSON object for our EntityReference input parameter can be specified like this.

{ "TeamId": {
	"@odata.type": "Microsoft.Dynamics.CRM.team",
	"teamid": "2ab7a6d5-9a36-e611-80e7-c4346bc48ef4" 

D365 JavaScript Web Resource Library Usage

It’s fairly straight forward to find which Forms use a Web Resource with the ‘Show Dependencies’ option, but that will list Forms where the JavaScript library has been added to the form in the Form Libraries. This doesn’t give you any indication whether the functions in the JavaScript file have actually been used in the form.

Obviously, you can scroll through each Tab and Field in the Event Handlers to look for occurrences of an event, but if you are doing maintenance on a form you didn’t originally develop then it could take a while to scroll though all the possible events. The Event Libraries and Event Handlers are stored in the formjson column of the systemform entity so with a simple FetchXML query you can get a list of Forms that actually use functions from a particular library. The example below will return all Forms where the msdyn_/Utils/head.js Web Resource has been used.The key part is the Filter Condition that is looking for a LibraryName that matches our JavaScript library. The formjson content contains an array of EventHandlers that define the EventName, FunctionName and LibraryName.

  <entity name='systemform' >
    <attribute name='name' />
    <attribute name='formjson' />
    <attribute name='formactivationstate' />
    <attribute name='type' />
    <attribute name='objecttypecode' />
      <condition attribute='formjson' operator='like' 
         value='%&quot;LibraryName&quot;:&quot;msdyn_/Utils/head.js%' />

The next step is to figure out which EventHandlers, if any, use that library in those forms. To do that I created a simple LINQPad script to return a list of the functions in each form.

void Main()
	string url = "https://myorgname.crm6.dynamics.com"; 
	string username = "my.user@myorgname.onmicrosoft.com";
	string password = Util.GetPassword("d365-admin");
	CrmServiceClient conn = new CrmServiceClient($"Url={url};Username={username};Password={password}; AuthType=Office365");

	conn.OrganizationServiceProxy.Timeout = new System.TimeSpan(0, 3, 0);
	IOrganizationService orgService = conn.OrganizationWebProxyClient != null ? (IOrganizationService)conn.OrganizationWebProxyClient : (IOrganizationService)conn.OrganizationServiceProxy;

	string pagingCookie = null;
	EntityCollection formsCol = null;
	List<Entity> forms = new List<Microsoft.Xrm.Sdk.Entity>();
		string fetchXML = $@"<fetch>
		  <entity name='systemform' >
		    <attribute name='name' />
		    <attribute name='formjson' />
		    <attribute name='formactivationstate' />
		    <attribute name='type' />
		    <attribute name='objecttypecode' />
		      <condition attribute='formjson' operator='like' value='%&quot;LibraryName&quot;:&quot;msdyn_/Utils/head.js%' />

		formsCol = orgService.RetrieveMultiple(new FetchExpression(fetchXML));
		if (formsCol.Entities.Count > 0)
		pagingCookie = formsCol.PagingCookie;
	while (formsCol.MoreRecords);

	forms.Select(e => new
		Name = e.GetAttributeValue<string>("name"),
		FormJSON = e.GetAttributeValue<string>("formjson"),
		Functions = System.Text.RegularExpressions.Regex.Matches(e.GetAttributeValue<string>("formjson"), "(\"EventName\":(.*?)},)", RegexOptions.None).Cast<Match>().Select(m => m.Value).ToList()

Since the formjson content is just a string, I used a Regex pattern to find multiple occurrences of the Event Handlers for each form. The result is a list of the EventNames, FunctionNames and LibraryNames for each form that utilises the JavaScript library in the FetchXML statement.

D365 Portals – Language agnostic Content Snippets

When dealing with multi-language websites Content Snippets are a great way to separate out your language specific portal content from your Web Templates and Page Copy.

If you want to use a single Content Snippet across all of your portal languages, for example with generic HTML that is language agnostic, then all you need to do is ensure the value in the Content Snippet Language field is left blank.

D365 Portals – Parent Web Links and Authenticated Users

When you need to display a multi-level web link set the parent level web link does not need to have a page defined. However, this means that the parent level web link will always be visible. If the child web links are behind Restrict-Read web pages, then unauthenticated users will always see the parent level menu option, even if they can’t see the children. Although this is not a major issue as the menu item does not go to a page, it can be confusing to the users if they click on the menu item and it doesn’t go anywhere.

To overcome this problem we can assign a blank page to the parent web link using the Blank Page Page Template. The screenshot below shows the configuration for the parent web link page.
Blank Page

After creating the page we create an Access Control Rule (Restrict Read) that is linked to the Authenticated Users Web Role.
Blank Page - Access Control Rule

Having configured the page, all that is left to do is link the page to the Web Link.
Web Link

Now the Parent Web Link is only visible once the user has logged into the portal and not displayed to unauthenticated users.

D365 Portals – tokenhtml

If you need to refresh the __RequestVerificationToken on your page, this is stored as a hidden input field but can be generated on demand by loading /_layout/tokenhtml.

In my case, I apply the token to a form posting to ensure the request is valid.

    $("#antiforgerytoken").load("/_layout/tokenhtml", function() {
        console.log("tokenhtml loaded");

D365 – System Views – Does Not Contain Data

The Advanced Find functionality within D365 v9 allows us to search for records that have no data in a related entity – a NOT IN query. For example, provide a list of Contacts that are not the Primary Contact for an Account.


However, if we try to create the same using a System View there is currently no option to do a NOT IN query.


To create a System View which contains a NOT IN query I had to complete the following steps.

  1. Create a basic System View with the required column layout and Publish the View.
  2. Using XrmToolBox and the View Designer Plugin I opened the System View and edited the query (using FetchXML Builder)
  3. Finally, save and publish the changes to the System View.


A few things I have found when creating NOT IN System Views.

    1. The System View does get created in the list of System Views for the entity and displays the correct content.


    1. When you open the Advanced Find from the System View, the filters for the System View are displayed correctly but the name of the System View we created is not listed.


    1. When you re-open the System View in the D365 solution after you have made the NOT IN modification, the option to Edit the filter criteria is no longer available. Any additional changes to the System View would need to be made using the XrmToolBox View Designer Plugin.


D365 Portals, Liquid Templates and FetchXML

My challenge today was to create a Web Template for a D365 Portal that returned a JSON object from a FetchXML query. There are a few blog posts around on how to achieve this, including this one from my colleague Nadeeja.

The complication for me was the FetchXML contains an ‘in’ operator which would contain a dynamic number of values.
The solution requires the creation of a Liquid array which can then be used in the construction of the FetchXML. To create the array I pass a comma separated list of values of GUIDs I need included in the query. Using the Liquid Assign variable tag i can create the array.
{% assign groupIds = request.params['groupIds'] | split: ',' %}
Within the Web Template I can iterate through the array as part of the construction of the FetchXML query.
To test the response I created a POST within Postman to the URL and supplied the named parameter, groupIds, as a comma separated list of values. The POST request is made using form-data and returns the relevant number of items based on the number of items in the groupIds array.