Multiple Control ID’s Error in Dynamics 365 Portals

Chandana's CRM Blog

Well I have started working as well as learning Dynamics 365 Portals. Seems like portals are quite interesting and bit tricky to play around. Lets move on to the scenario which I have faced.

My task is like to display a page in portal which contains account information. To achieve this I started creating a web page named “Account” which will use the entity form.

In Entity form I select account entity and account detail form to display the same on the portal. Now I am done with my changes and task as well. When I refreshed my portal to view the changes and account detail form, the portal does not show up. Indeed it throws up a weird error!!!!


I am dumbstruck, was not able to identify what actually went wrong. After some moment able to identify through error log which says like “Multiple Control ID’s…

View original post 54 more words


Show Lookup as Dropdown in Dynamics 365 Portals–Gotchas!

I have been working and providing training a lot recently on Dynamics 365 portals. And whenever I go over Metadata configuration of entity form the option – “Render Lookup as Dropdown” option excites the participants a lot.

Well, in this article I am not going to show how you can render a lookup as dropdown. Rather I would like to highlight what features you loose when you render your lookup as dropdown.

Gotcha 1 – No Values shown in DropDown

When you render your lookup as dropdown, the first thing you observe that the list is empty. Well, this may happen because there is a bit of change in this implementation. Right now the options will only show up is you enable entity permission for the entity which is shown as lookup.

For example – Primary Contact field on the account form. When you render your Primary Contact as dropdown in Portals, you need to have an entity permission for contact entity with Append privilege for the webrole the user is logged in with. The contacts will show up then.


Gotcha 1 – Lookup filtering not working.

Well this is something undesirable but as of the day I am writing this blog, related records filtering does not work for lookups rendered as dropdown.


Short article but should put you in good stead next time your customer asks for this option.


Debajit Dutta

(Dynamics MVP)

For consultation/ training visit or reach out to us at

{Step by Step Guide} Query Dynamics CRM Web API using Server to Server Authentication with Application User

I have wrote quite a few articles over the last one year to query Dynamics Web API using ADAL from client side and as well as server side. However lately I am receiving loads of queries on how to Authenticate with web-API without using any user credential or how to authenticate with new Server to Server (S2S) authentication.

I thought of providing some good links already available there. However I feel that some of the steps mentioned are not pictorially represented. Hence penning down this blog for the benefit of my blog readers.

In this example I will give a complete example of querying the list of account through Web API from a External web app and not just getting the bearer token.

There are two steps to this example

1. Get the token Authorization token from Azure

2. Send the authorization token to get the list of accounts from CRM using the Web API endpoint.


Step 1: Register your application with Azure to get the Client ID and Client Secret



  • Enter the necessary information. Name is anything you wish to give. Sign-on Url is my website’s sign-on page.


  • Once the application is created then note down the Application ID and then click on Settings. You Application ID here is the Client ID.


  • Click on Required Permissions –> API’s –> Select an API and choose – Dynamics CRM Online


  • Choose Delegated permissions as highlighted below and the save your settings in Azure.


  • Then click on Keys. Enter the key name to get a key value. Copy it immediately and store it. It is your client secret.



Step 2: Use ADAL in your Code to get the bearer token

The next step is to get the bearer token. To do this, open your project and through Nu-get package manager, add reference to the latest version of ADAL.



Below is the code to get the bearer token. Please read the comments to make the code work for your organization.

ClientCredential credential = new ClientCredential("<replace with your client id>", "<replace with your client secret>");

string authorityUri = ""; // here is my crm domain. Please replace with your domain
TokenCache tokenCache = new TokenCache();

            AuthenticationContext context = new AuthenticationContext(authorityUri);
            AuthenticationResult result = await context.AcquireTokenAsync("", credential); // is my CRM URL. You need to use your crm url to test this.

            var authToken = result.AccessToken;


Please observe, we have not used the credentials of any user anywhere.


Step 3: Get the accounts from CRM.

So far you may be thinking that this is what we have already tried before as well. What’s new in this.

Well I take the below piece of code and try to load my account list.

public async Task LoadAccount(string bearerToken)
            var httpClient = new HttpClient();
            httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", bearerToken);
            ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12; //

            var result = httpClient.GetAsync("$select=name").Result;

            var accountJSON = await result.Content.ReadAsStringAsync();



However I receive 401. Unauthorized error.

If you are feeling now it’s time to learn something new, you are right. But before we go ahead, let’s understand why you are getting unauthorized error. After all, in Azure I gave the app to access Dynamics as a Organization user.

That step enabled the client application to access Dynamics CRM by using the Application ID and the client secret. Your client application is now able to be authenticated against Azure AD with permission to access CRM Online. However, CRM Online does not know about this "client application" or "user". CRM API will response a 401 if you try to access it.

So let’s jump to step 4.


Step 4: Create an Application User in CRM and assign security roles to it.

Well this may be a previous step but I deliberately put it in the last one to make you understand the unauthorized error.

Go to CRM –> Security –> Users and switch the view from the default view to “Application Users”.



Click on the New button to create a New Application User. You may be landing to the user form by default. Change the form to application user form.



In the application ID, enter the application ID of your app you obtained from Azure in Step 1.

I put the name of the user as – WebApp Application User

Email I put as – I have used my domain. You better use your CRM domain. The name will automatically populate from the email you give. Once you save the record, CRM will auto populate the Application ID URI and the Azure AD Object ID.


Now in this example we are trying to retrieve account records. So it’s better you create a custom security role and assign to this user which will give the application user read permission on the Account record. I copied the Salesperson role and then assigned to this application user. Basically whatever operation you want to perform using Web API, you need to provide the same privilege to the application user.

Now when you run the code in Step 3, this time you get the account JSON. The icing on the cake is Application user won’t consume CRM licenses as well.

Hope this was helpful for you guys.


Debajit Dutta

(Dynamics MVP)

For consultation/ training visit or reach out to us at

{Utility} Automatic Roll-up calculator for Dynamics 365–from XrmForYou

Frustrated about customers complaining that Roll-up fields are not calculating at runtime? Abandoned rollup fields and went for something custom because customer couldn’t afford the calculation to happen every hour? The good news is that you do not need to worry about all these any longer. The new Automatic Rollup Calculator solution from XrmForYou tackles all these scenario and does much more.

Dynamics 365 offers a wonderful UI based editor to define your roll-up fields. It’s quite powerful. However whenever we go to customer and say that roll-up fields are not calculated at run-time, it puts us in some shaky situation. Our tool does the following:

  • Identifies any changes in the child entities involved in the roll-up field definition and automatically calculates the roll-up field values
  • Handles scenario when
    • Child record is created
    • Child record is deleted
    • Child record is updated. Handles both the scenarios when associated parent of the child record is changed or the field of the child entity involved in the calculation of roll-up field is updated.
    • On-demand calculation of all roll-up fields of a record.

And all of these with just few configuration steps. So let’s see how our tool works.

For trial and pricing, please write to us at Video and documentation coming soon on website.

The tool comes in the form of managed solution. Once you install, it will appear in your solutions area.

Solution Name – XrmForYou.RollupfieldCalculator.


Open up the solution and navigate to the configuration Page. You will see a screen like the one shown below.



For this documentation, I have set up the following structure.

  • Created an Entity – Test Entity
  • Set-up 1:N relationship with Contact
  • Created two roll-up fields
    • Count of Contacts – Rollup field showing the number of contacts associated with the Test Entity
    • Contact Credit Limit Sum – Rollup field showing the aggregate of the credit limit field of the contacts associated with the Test Entity.

Definition of both the fields in screenshots below.

image                  image

Okay. So far so good.

I select my Test Entity from the DropDown and all the roll-up fields of the entity shows up.



This UI helps me pick and choose which roll-up field I want to enable for automatic calculation

I select both and click on Save Configurations button. The system will start setting the roll-up field configuration for the selected fields. You can monitor the state of the operation by going to Settings –> System Jobs

JobName – x4uru_ActionRegisterSDKStep.



If the job fails, you need to open and see the error. If the job succeeds, it will disappear from the system jobs list.

Once successful, you are all set.

For testing I create two records – “Test Record 1” & “Test Record 2”.

For both the records the roll-up fields are showing 0 which is expected.



I open up Test Record 1 and associated 4 contacts.



If I now refresh, my advanced find view, I can immediately see the roll-up fields being updated.


Please note that in order to avoid any performance issues, the roll-up field calculation happens through asynchronously the moment any changes are made to the child entity. Hence if your async job is stuck sometimes you may experience a bit of delay. But usually all this will happen within seconds of updating the child entity.

Now I open up any contact associated with Test record 1 and associate it with Test Record 2.

Immediately when I come back and refresh my advanced find view, I can see the results.



Cool. Now before I wind up, there is one more feature that the tool comes with. Once you install the solution and open up any entity form, you will see a new button in the Menu called – “Calculate Roll-up Fields”.


Say you don’t want to go for automatic calculation but you want the user to have an option of updating all the rollup fields on a record on-demand. You have this option which allows you to do exactly like that.

Click on the button and the dialog pops-up where you can pick and choose the roll-up fields to be updated.


Select the desired fields and then click on Update. The page will refresh to show the latest roll-up data.

If you believe this tool works for your organization, you can request for trial and pricing at

Video and documentation will be uploaded in our website soon.


-Debajit Dutta

(Dynamics MVP)

Sharepoint Metadata Manager and Attachment Extractor–New version released!

We are delighted to announce the release of the next version of our tool – Sharepoint Attachment Extractor and Metadata Manager. For readers who are new to this tool, this tool enables you to upload documents to Sharepoint with multiple metadata as well as host of other features like

    • Allows you to create and edit Metadata related to files from CRM. This version allows up to five metadata fields per entity and also provides the option to restrict the metadata values to a specific set of values or free text.
    • Dynamic adding and removal of the SharePoint section on the form of an entity just through configuration page that comes with the tool. Also you can place the SharePoint section on multiple forms for the entity.
    • Upload up to five files at one go along with the option to enter metadata for each file. Also size limit of file not constrained by the attachment size limit in CRM
    • Automatically moving the document from the annotations section of CRM to Sharepoint.
    • Behaves in conformance with the security privileges of the user in CRM for the record on which the SharePoint section is being shown.

You can download the detailed documentation from this link –


For trial and pricing, please write to us at


So what’s new in Version 2.0?

1. Performance

Our team have worked greatly on the performance issues especially during metadata update and also during upload of five files with metadata. The current version is ~1.5x faster than its previous version in terms of interaction with SharePoint

2. UI in conformance with Dynamics V9.0

The entire look and feel of the Sharepoint Grid control has been revamped in conformance with the new version of CRM. The grid contains a host of features including

  • Column resizing
  • Improved Searching logic
  • Sorting
  • Paging
  • Document reload
  • Drag  & Drop

Screenshots for reference.







3. Ability to specify column ordering for metadata

The tool now comes with the capability to enable column ordering for metadata.





All of this and much more to offer. Reach out to us to know how we can help you.

For trial and pricing, please write to us at


-Debajit Dutta

(Dynamics MVP)

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