Calling bound actions (entity actions) using Xrm.WebApi.execute in Dynamics V9

This is a follow up to my previous blog where I showed you how can you call a global action with all parameter types using the newly introduced Xrm.WebApi.execute method.


Now coming to bound actions i.e actions which are bound to entities, I was getting multiple queries on how to do it after my first blog post. Readers were telling that they are unable to call the action after repeated trials. I was perplexed. So I thought, why not give a try.

So I created a very simple action with the below details:


Name: new_TestProcess

Bound to entity: Account

Input Parameter – EntityReference of type custom entity named new_TestEntity



So harmless isn’t it. Even I was thinking the same till it took me more than couple of hours to figure out on how to call this action using Xrm.WebApi.execute.

So let’s dive into the code. The first thing we need to understand is how to pass the parameter for the bound entity. In other words this action will always be called on account record. And how do you pass the account record reference?

Well, the first thing that came to my mind is the input parameter must be named as “Target”. After all that is the convention created by Microsoft right? Well in-fact it’s bit different. It’s not “Target”. Then how do I find out the parameter name.

  • Settings –> Customizations –> Developer resources
  • Dowload Web Api Metadata


  • Once downloaded, open up the metadata in Visual studio or any other XML editor of your choice. Search for your action. In this case – “new_TestProcess”.
  • Below is my metadata for my action. See the highlighted line. From that it is clear that the bound entity parameter type is “entity” and not “Target”



Ok, past the first hurdle. Now comes my nightmare.

Highlighting Microsoft Documentation for Xrm.WebApi.execute below


Well, a very detailed documentation I would say. Everything is pretty much explained. But let’s shift our focus to to the highlighted line which says that for entity actions, we need to set the boundParameter to entity logical name or entity set name. Well, that’s when my ordeal started.

Started with all possible combinations like “mscrm.account”/ “Microsoft.Dynamics.CRM.Account”/”account”/”accounts” and a host of illogical others which are all ridiculous. Smile

Finally just before giving up , I started debugging and went around whichever files the browser takes me in while debugging. And finally eureka moment when I realized that you need to set the value of boundParameter to the word “entity”. Could anyone imagine that from the statement in the documentation.

And finally piece of code below for you

var target = { entityType: "account", id: "78FA0233-7D86-E811-A94D-000D3A3AB6B4" };

    var reqObject = {};
    reqObject.entity = target;
    reqObject.ArgEntRef = { "@odata.type": "Microsoft.Dynamics.CRM.new_testentity", "": "C182D39E-6B8B-E811-A94D-000D3A3AB6B4" }

    reqObject.getMetadata = function () {
        return {
            boundParameter: "entity",
            operationType: 0,
            operationName: "new_TestProcess",
            parameterTypes: {
                "entity": {
                    typeName: "mscrm.account",
                    structuralProperty: 5
                }, "ArgEntRef":{typeName: "mscrm.new_testentity",
                    structuralProperty: 5}

        function (data) {
            var e = data;
        function (error) {
            var errMsg = error.message;


Hope this helps!

-Debajit Dutta

(Dynamics MVP)

For consultation/ training visit or reach out to us at


{knowhow} Show terms and conditions page in Dynamics 365 Portals

With the new version of Dynamics 365 Portals, it is now possible to enable General Data Protection Regulations (GDPR) in portals.

You can throw up company terms and conditions page when a user is authenticated to the portal. Let’s follow the below steps

To start with Navigate to Portals –>  Content Snippets

Check for the below content snippets. If its already there, don’t create. Duplicate records may lead to improper functioning.

Snippet 1:  Account/Signin/TermsAndConditionsHeading

This is the header of your terms and conditions page. I Set the value – “Custom Terms and Conditions”.



Snippet 2: Account/Signin/TermsAndConditionsCopy

This is the body of your terms and conditions  and you can place your HTML stuff in here.



Snippet 3: Account/Signin/TermsAndConditionsAgreementText

This is the text which is usually displayed beside the checkbox in the terms and condition page, usually at the bottom of the page.



Snippet 4: Account/Signin/TermsAndConditionsButtonText

The text of the button in the terms and conditions page.



Now we are done with four basic settings. However just putting in these settings won’t enable the terms and conditions for your portal. There is another site setting that you need to create if not already created.

Go to Portals –> Site Settings and create the below setting. In most of the cases it will be there already and you may just need to switch the flag from false to true. Don’t create duplicate settings

Authentication/Registration/TermsAgreementEnabled. It is a Boolean flag which indicates whether terms and conditions are enabled for your portal. Set it a value of true.

There is another site setting that you need to lookout for. Authentication/Registration/TermsPublicationDate. It’s a date value which determines from which date is the terms and conditions applicable. If any user who has logged in to the portal and he/ she has not accepted the terms and conditions after the date specified, the user would be asked to Agree the moment they sign in.



To identify when a contact has accepted the terms and conditions, there is a field in contact which captures this value. It’s called Portal Terms Agreement Date.


Hope this helps! Happy CRMing.


Debajit Dutta

(Dynamics MVP)

For training/ consulting/ utilities – please visit our website – or write to us at

Change Base URL of Dynamics 365 Portals

A good news for portal users. With the latest Portal update, it is now possible to change the Base URL of a portal after it has been provisioned.

To change the base URL of the portal open you Portal administration through Office 365 login.




In the last screen above just scroll down to bottom and you will see a new tile – “Change base URL”


On Clicking it asks for a new sub-domain.



My initial URL was . I changed it

It will take a moment and then the portal will be restarted.

Then you will be able to browse the portal with the new URL.

Hope this helps!


Debajit Dutta

(Dynamics MVP)

For corporate training/ consulting, please write to us at

Thanks To all my blog readers and Microsoft for the Microsoft Most Valuable Professional Award 2018-2019

A big thank you note to all my blog readers without whom this has not been possible. It’s been a great journey so far and undoubtedly it’s my blog which has helped me in this.

Big thanks to Microsoft as well and once again thanks to everyone for every read of my blog. I hope it has been useful to you as much as it has been useful to me.

Keep reading, keep learning, keep sharing.



Debajit Dutta

(Dynamics MVP)

For training/ consulting/ utilities – please visit our website – or write to us at

CRM on-premise to Sharepoint online integration–Common obstacles faced and their work-around.

Before I start writing the details, first let me tell you why this blog. After all this is so nicely explained in the following link –

Well, the above link contains all the steps you need to set-up server-server integration between Dynamics On-Prem and Sharepoint online. But still from my personal experience I find that customers find it great difficult to set this up. This is mainly because they get some error while executing a step or because some pre-requisites are not there and they are not mentioned in the technet link as well.

The main intention of this post is to rectify all those errors, identify all the dependencies and work your way to glory.

So let’s identify the dependencies first.

Dependency 1 : Dynamics should be ADFS configured and accessible over the internet.

I am not going over the topic again on how to do it. Greatly explained here – and in so many other blogs.


Dependency 2: Microsoft Dynamics 365 Hybrid Connector should be configured.

Believe me, from my personal experience I find many clueless about this. Well you no longer need to. You just need to verify here if Dynamics 365 Hybrid connector subscription is available and commissioned.

To do this:

  • Login to using the Office 365 admin credentials for your SP online tenant.
  • Open the Office 365 admin screen
  • Go to Billing –> Purchase Services


  • Expand the section Dynamics 365 Suite. Usually its expanded. If not expand it.



    • Below is the screen you get. As of now its free but the way it shows up I believe it will be chargeable some time soon Smile


    • Enter you credit card number and then click on Place Order. Don’t worry, you won’t be charged for this. You are all set and done.


Dependency 3: Connect to Microsoft Online through PowerShell.

Now this can become tricky. The technet documentation says – You need to have Azure Active Directory powershell modules. And the link redirects you to a page where it asks you to install the module using Powershell command prompt – Install-Module MsOnline

The moment you do this step, you get an error like the one below.

install-module : The term ‘install-module’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path
is correct and try again.
At line:1 char:1
+ install-module MSOnline +
+ CategoryInfo          : ObjectNotFound: (install-modele:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException


Well to successfully accomplish this, you need to complete both the required steps.

  1. Microsoft Online Services Sign-In Assistant for IT Professionals Beta – select the appropriate download. It may ask you to restart the machine for the changes to take effect. Please do the same.
  2. Now also if you run the install-module command, it would fail. The reason is install-module command is available from Powershell v5.0 and above. So you need to update your powershell as well. To do this, download the necessary installer depending on your server/ 64 or 32 bit machine, from the below Url.

Again machine restart is required.

Now open powershell as administrator and then try to install the module MSOnline. It will now download the same from Nuget.


Requirement 4: X.509 Digital certificate

Well this is the simplest but again it can give you some errors which would be difficult to find out. The first question is – which certificate do I need to use.

Well, the easiest answer is, you can use – “An x509 digital certificate issued by a trusted certificate authority that will be used to authenticate between Dynamics 365 (on-premises) and SharePoint Online. If you are evaluating server-based authentication, you can use a self-signed certificate.”

So we can basically re-use your CRM certificate or ADFS certificate. All you should take care is while exporting the certificate, it should be exported along the private key.



* Export all extended properties should be checked.



You will be asked to provide a password. Keep this password as you will need this later.



Once the file is exported, import it in the personal store of the machine where deployment manager is installed.

The technet article asks you to execute the below command.

$CertificateScriptWithCommand = “.\CertificateReconfiguration.ps1 -certificateFile c:\Personalcertfile.pfx -password personal_certfile_password -updateCrm -certificateType S2STokenIssuer -serviceAccount contoso\CRMAsyncService -storeFindType FindBySubjectDistinguishedName”

The service account is important here in the above statement. Whatever service name you provide here, that should have access to the private key of the certificate. To do that, you need to provide permission to the private key from the certificate console.
Click on Manage Private Keys and give the service account user full permission on the certificate.
After completing all the above steps, while connecting to your CRM, you may receive the 401 - Un-authorized error in Powershell. For this follow the below steps.

Open registry editor


    1. Right-click Lsa, point to New, and then click DWORD Value.
    2. Type DisableLoopbackCheck, and then press ENTER.
    3. Right-click DisableLoopbackCheck, and then click Modify.
    4. In the Value data box, type 1, and then click OK.

Re-open powershell. It should work.

The commands I am not repeating from the technet article since they work just fine.
Hope this helps!

Debajit Dutta

(Dynamics MVP)

For training/ consulting/ utilities – please visit our website – or write to us at


{Quick Tip} Manage your Entity Forms when your CRM is exposed to Web and Mobile App

Spoiler alert! Unlike other blogs, I am not going to update you about any new feature. Rather I am going to share my project experience in handling multiple forms designed for your Web and Mobile layouts.


You have exposed you CRM recently to Mobile Apps. When you expose your CRM to Mobile Application development, in most of the scenarios you would end up designing separate forms. Let’s take the example of Account entity. Say you have designed two forms

  • Account Web Form – This form is displayed to users while accessing CRM to Web
  • Account Mobile Form – Form displayed to users while browsing CRM on Mobile

And you have your users who will just access CRM through desktop and then some users accessing CRM through both Desktop and mobile.


So now the implementation

First of all, as I have been across client locations, I find that some consultants still assume that to expose a form in mobile, we need to create a form of type = ‘Mobile Express’. Mobile express forms were required for previous Dynamics app – Dynamics CRM Phone express. For the current version of Mobile App for Dynamics, Form Type = Main would work just fine

So what is the next step? We create a new form of type Main, this time specifically for mobile and put in only the fields required for Mobile as per the requirement. But wait, we have another form already exposed for the desktop. So how do we handle this.

  • Create a new security. Let us name it here – “Mobile User Security Role”. The privileges for this security role is optional and depends on your requirements.
  • Assign the security to users who need to access CRM on mobile.
  • In the Form order for Main Form set, set the Mobile form at the top of form order.


  • The next step is to leverage the role based forms. Expose the Account – Mobile form to only users with Mobile User Security Role.


Uncheck the “enabled for fallback” checkbox as well.

Save an publish your customizations.

All set and done. Now this works very well for users who does not use desktop and manages through mobile (hardly the case) and users not exposed to mobile platform. However the issue is for a user who has access to mobile and desktop version. They now see two forms and the mobile form starts showing up in the desktop as well as it is highest level in the form order as well.

The last step here is to switch the mobile if it loads on desktop. The simple piece of client side script would just work fine when put in form load of the mobile form.

function SwitchToDefaultFormForWebVersion(){

        var _defaultFormName = "account web form";

        var _isMobileClient = Xrm.Page.context.client.getClient() == "Mobile";

        if (!_isMobileClient) {

            var availableForms = Xrm.Page.ui.formSelector.items.get();

            var currentForm = Xrm.Page.ui.formSelector.getCurrentItem();

            if (currentForm != null) {

                var currentFormLabel = currentForm.getLabel();

                if (currentFormLabel.toLowerCase() == _defaultFormName)



            for (var i = 0; i < availableForms.length; i++) {

                if (availableForms[i].getLabel().toLowerCase() == _defaultFormName) {






Please remember that form navigation script is not supported on mobile. Hence first I am making the check if the client is Mobile.

Well there you go. Everything is up and running for you now.


Hope this helps!


Debajit Dutta

(Dynamics MVP)

For training/ consulting/ utilities – please visit our website – or write to us at

Open Lookup Dialog Programmatically using Xrm.Utility–Dynamics V9.0

This one feature that I am going to pen down here, personally I have longing for it quite sometime now.

So before going into the HOW part of it, let’s understand the why part of it? When do I need show a Lookup dialog Programmatically? Well the answer is, numerous occasions. Like if you need to throw up a lookup dialog on change of field on the form OR you needed to throw the lookup dialog on click of a button on a web-resource.

All this time, we have achieved this but not in a supported way. Probably we may have ended up using Xrm.Internal.openDialog or some method of Mscrm.Internal namespace. But all these are unsupported and mere workaround to this perennial problem.

Well, no more messing around. Microsoft has finally brought in the Xrm.Utility.lookupObjects.

So let’s see how it works.

Let’s take a not so good example here. Let’s say whenever the account country is US, primary contact is mandatory and the user is thrown a lookup dialog of contacts from where he needs to select the Primary Contact. below if the function registered on change of country field

function changeOfCountry(e) {
    var formContext = e.getFormContext();

    if (formContext.getAttribute("address1_country").getValue() == "US") {
var lookupOptions = {};
        lookupOptions.allowMultiSelect = false;
        lookupOptions.defaultEntityType = "contact";
        lookupOptions.entityTypes = ["contact"];


            function (result) {
                if (result != undefined && result.length > 0) {
                   var selectedItem = result[0];

                    formContext.getAttribute("primarycontactid").setValue({ entityType: selectedItem.entityType, id:, name: });
            function (error) { }

Focus on the highlighted lines starting from top. The first is the lookupOptions paramter. Since we are going to open a contact, I have specified defaultEntityType and entityTypes both to contact.

Also you can set the defaultViewId and the viewIds property to show the default view to use and views to be available in the view picker respectively

For a complete set of the properties of lookupOptions refer to Microsoft Documentation.

As soon as the method is executed, the below dialog opens up


Cool isn’t it? Now half of the job is done. But how about getting the selected record back. Well this method does not disappoint you here either.

The success callback function returns the selected item as you can see from the code above.

It has properties of entityType, id and the name which you can use to set the look up field of any other type. Here I have used the same to set the value of primarycontactid field of the account record.

Such a huge sigh of relief for me.

Hope this helps!


Debajit Dutta

(Dynamics MVP)

For training/ consulting/ utilities – please visit our website – or write to us at