As promised, I am back to my second post on this topic. In my previous post, I showed you on how to generate Authorization token of D365 online from Native Console App using the Client_ID.

https://debajmecrm.com/2018/04/29/headless-authentication-with-dynamics-crm-online-web-api-without-user-login-screen-without-using-adal-part-i/

We did that using simple HttpWebRequest and Response and did not use the ADAL (Active directory authentication library) as well.

Well, let’s dive deep here. Nothing big in my previous topic as the same thing can be done using ADAL and in a clean way as well. Then why use that construct?

We are talking of headless authentication here which means authentication without user intervention. Using ADAL, it was fine to generate the token from a Native console APP using the Client ID. However situations become complex when we try to do the same from an external Web Application which required the Client_Secret as well for generating the token.

So I created a ASP.NET…

Well this topic has been discussed again over multiple times. And I myself has written a blog on how to do a headless authentication (without user intervention) between Dynamics CRM Online Web API and Native APP (console APP) – https://debajmecrm.com/2016/06/21/dynamics-crm-web-api-login-authentication-screen/

If you go through the above post, I have used ADAL (active directory authentication library) to query the authorization token and then use the authorization token to query the Dynamics CRM Web API. However there is a catch to this.

This headless authentication was only possible with Native APPs (console APPs) since they just required Client ID’s and does not require the Client Secret to actually generate the token. And hence I was not able to use this method to get the token from a Web Application which would require the Client_Secret.

And while I was doing a training session on this recently, I was asked the question. Is there…

Dynamics 365 9.0 has introduced a new feature that enables adding field dependency with a JavaScript web resource. It gives below benefits

1. It will restrict deletion of field(s) if it is being consumed in a js web resource. In earlier versions user was able to delete field(s) even if it is used in a js logic, and it causes exception in js execution.

   

2. Dependent field(s) value will be available on form UI, even if it is not added on form. That’s right you don’t have to fetch its value from CRM now (earlier we have to fetch field(s) value using odata or web API if it is not available on form and its value is needed in js logic.)
3. js web resources will be shown in field dependencies.

   

   To add attribute dependencies, follow below steps

   1. Open a web resource (from a solution, this option is not visible if you open…