Non-interactive Access Mode

Why would you want to set Access Mode for user to Non-interactive? 

Setting the Non-interactive access mode fro a user will prevent him from accessing Dynamics 365 application UI in any official Dynamics 365 client: Web, Outlook and mobile. While human users need an GUI to actually do some work, external applications interacting with Dynamics 365 do not. Note that security mechanism such as Security Roles, Field Level Security etc. apply to users with Non-interactive access mode just as Read-Write users.

Assigning the Non-interactive access mode to applicative users used for interaction with external applications is a good security best practice as long as you assign the most restrictive Security Roles rather than System Administrator. This way, if this user’s credentials are breached, a potential attacker can access via API only, limited to the data scope and operations dictated by the Security Roles to begin with. 

If you do use the Non-interactive access mode for applicative user, consider the password renewal policy for this user, as there is not human on the the other side to actually change the password. This means that dependent integration points may fail due to expired password.

For more details about setting up a Non-interactive user follow this article.

Advertisement

Accessing Form Header Web Resource

Although this Help article states that with Microsoft Dynamics CRM 2016/Online “You can’t include a web resource in a form header or footer”, you certainly can.

Sadly, form Footer Web Resource no longer display any content (as it did in version 2015). Form header displays content correctly, but adding it will spread the header fields all over the form width.

If you are ok with the UI, you might want to access the header Web Resource programmatically via JavaScript. Maybe when a form attribute value changes, the Web Resource content should change dynamically.
Unlike header attributes, which can be accessed using  Xrm.Page.getControl(“header_name”), the header Web Resource can not be accessed this way as it seem to be invisible to the getControl function.

So how can the header Web Resource ‘Listen’ to form and field events?

Since Web Resource can access the Xrm.Page object via the parent object, it has full access to the form elements and events. The addOnChange function allows the the Web Resource code to register an internal function as an event handler for a form or field event.

The following sample demonstrates HTML Web Resource located in the Account form header area, ‘listening’ to the Account Name attribute change event. 
The code is located in the HTML Web Resource:

//register event handler to the account name attribute onChange event

function registerRefreshEvent()
{
    if(parent.Xrm.Page != null)
    {
         parent.Xrm.Page.data.entity.attributes.get(“name”).addOnChange(refreshContent);
    }
}

//do something with the Web Resource content…

function refreshContent()
{
    alert(“Refreshing Web Resource content…”);
}

registerRefreshEvent();