Access Mode & integrate CRM without requiring a Licence user in Dynamics CRM.

The goal of this blog post is to inform you about the below mentioned points:

1. Access mode in Dynamics CRM, how can we create it.
2. How can we save the licences for a non-interactive user and administrative access user and reduce the cost of the project?
3. How can we overcome new request limit that Microsoft is putting to access their Microsoft Power Platform request (Connectors, Microsoft Flow, Common Data Service) effective from October 2019 as shown below?
4. Updated October 2019 for new API introduced limitations.

“Effective October 2019, to help ensure service levels, availability and quality, there are entitlement limits to the number of requests users can make each day across model-driven apps in Dynamics 365 (such as Dynamics 365 Sales and Dynamics 365 Customer Service) PowerApps, and Microsoft Flow”

Number of API requests / 24 hours

Dynamics 365 Enterprise applications: 20,000

Dynamics 365 Professional: 10,000

As we all know there are three types of Access mode in Dynamics CRM 365, which we can assign to a user or service account based on business requirements.

1. Read-Write
2. Administrative
3. Non-Interactive

1.    Create a Read-Write user account

Whenever, we assign a Dynamics CRM Licence to a user from Microsoft 365 Admin Centre, by default user get Read-Write access mode in Dynamics CRM instance. I will not explain more on this, as this mode consume licence and used by normal users who wanted to perform day to day work in Dynamics CRM.

2.    Create an Administrative User

An Administrative user is a user who has access to the Settings and Administration features but has no access to any of the functionality. It is used to allow customers to assign administrative users to perform day-to-day maintenance functions such as create user accounts, manage security roles, teams etc. Since the administrative user does not have access to customer data and any of the functionalities, it does not require a license after setup.

2.1      Creation of Administrative account

We need to have the appropriate security role in office 365 and in CRM to create an administrative user in Dynamics CRM from Microsoft 365 Admin Centre.

• First step is, you’ll create a user account in Microsoft 365 Admins Centre.
• Assign a Licence.
• While creating user > Uncheck the User (no administrator access) box in optional settings.
• Check the service administrator box.  
• Note: if you have selected Global Administrator box, you don't need select this option.
• Wait for user to sync to the CRM environments
• Then in Dynamics 365, select the Administrative access mode for the account.
• Third give appropriate security role in CRM based on the requirement, so that the administrative user can be restrictive in CRM.
• Then go back again to Microsoft 365 admin centre and remove the licence for the user, so that it won’t consume any licence for Dynamics CRM Access.

Note: If you are a Global Administrator, automatically in CRM will have an account with Administrative Mode and have System admin privileges

3.      Create a Non-Interactive Users

Here we go, the Non-Interactive Users are game changer in terms of reducing the licence cost and Dynamics 365-integrate without requiring a licensed user.

The non-interactive user is not a ‘user’ in the typical sense – it is not a person but an access mode that is created with a user account. It is used for programmatic access to and from model-driven apps in Dynamics 365 between applications. A non-interactive user account lets these applications or tools, such as a model-driven apps in Dynamics 365 to ERP, MuleSoft connector, authenticate and access model-driven apps in Dynamics 365, without requiring a license. For each environment, you can create up to seven non-interactive user accounts, however I will also tell you how we can create more than 7 non-interactive user accounts in CRM so that we can leverage it broader term.

However, before showing how to create a Non-Interactive user account, would like to discuss the new changes that MS has putting in request limits and allocations. Why I would like to discuss this before because we can take advantage of Application User (which is practically a Non-Interactive access mode user account) to overcome this request limit to the number of requests users can make each day across model-driven apps in Dynamics CRM (such as Dynamics 365 Sales and Dynamics 365 Customer Service Apps). For more info you can refer below MS link.

https://docs.microsoft.com/en-us/power-platform/admin/api-request-limits-allocations

Below, I tried to give a brief summary about the above MS Link.

Microsoft Power Platform request allocations based on licences (Effective October 2019)

All the users of Microsoft Power Platform can use a certain number of requests based on the license they are assigned. The following table defines the number of requests a user can make in a 24-hour period.

If a user has multiple plans assigned from different product lines, the total number of requests allowed would be the sum of requests allocated to each license type. For example, if a user has both a Dynamics 365 Customer Service Enterprise license as well as a PowerApps per user license , then that user will have a total of 20000 5000 = 25000 requests available per 24 hours.

If a user has multiple licenses allocated within the same product line, for example if a user has a Dynamics 365 Customer Service Enterprise license as the base license and a Dynamics 365 Sales Enterprise license attached, the total number of requests would be what is provided by the base license - Dynamics 365 Customer Service.

Question: What is a Microsoft Power Platform request?

Requests in Microsoft Power Platform consist of various actions which a user makes across various products. At a high level, below is what constitute an API call:

• Connectors – all API requests to connectors from PowerApps or Microsoft Flow
• Microsoft Flow – all Microsoft Flow step actions
• Common Data Service – all CRUD operations, as well as special operations like “share” or “assign”. These can be from any client or application and using any endpoint SOAP or REST. These include but are not limited to plug-ins, async workflows, and custom controls making the above-mentioned operations.

Question: What happen when you exhaust and exceeds your Request capacity?

If any user exceeds request capacity, admin for the tenant/environment would be notified and would be able to assign PowerApps and Microsoft Flow request capacity to that user.

End users and integration will not be blocked from using the app for occasional and reasonable overages at this point of time.

PowerApps and Microsoft Flow capacity add-on allows customers to purchase additional requests which can be assigned to any user who has a PowerApps/Microsoft Flow license as well as Dynamics 365 license. These can be assigned to an application, and administrative and non-interactive users.

Each capacity add-on provides an additional 10,000 requests/24 hours which can be assigned to any user. Multiple capacity add-ons can also be assigned to the same user.

Question: What are Non-licensed users/application users/Users with special free licenses?

Common Data Service also provides the ability to have identities that do not require any user license to interact with the service. There are three types of these users:

• Application users
• Non-interactive users
• Administrative users.

For these above users, every tenant will get base request capacity per tenant which can only be used by these users and not by users with standard licenses.

This base request capacity would be based on the type of subscription and would be as follows for Non-Licenced users:

• If a tenant has at least one Dynamics 365 enterprise subscription, they will get 100,000 requests per 24 hours
• If a tenant has at least one Dynamics 365 professional subscription, they will get 50,000 requests per 24 hours
• If a tenant has at least one Microsoft PowerApps or Flow subscription, they will get 25,000 requests per 24 hours.
• If a tenant has multiple type of subscriptions, their base request capacity would be max of two subscriptions. For example, if a customer has both Dynamics 365 Customer Service and PowerApps per user subscription, their base request capacity would be 100,000 Requests per 24 hours.
• Base Request Capacity would be at tenant level and can only be used by non-licensed users, application users and users which has free ($0) licenses.
• Once the Base Request capacity is exhausted, customers can increase this capacity by purchasing PowerApps and Microsoft Flow capacity add-on.

Now, I hope you got it why I was saying to use Non-Interactive user for Programmatic API calls to Dynamics CRM as these users are Non-Licenced users and MS gives more request capacity to these Non-Licenced users in comparisons to Licenced users.

Continue…

Now, let’s come back on how we can create a Non-Interactive account in Dynamics CRM.

Actually, there are two ways through which we can create Non-Interactive account for programmatic access.

• Direct from Dynamics CRM365 and Admin Centre

• By Creating an Application user

3.1  Direct from Dynamics CRM365 and Admin Centre (These Users’ are created under Local AD, in which normal users are created)

Again, I am repeating a non-interactive user is not a ‘user’ in the typical sense – it is not a person but an access mode that is created with a user account. It is used for programmatic access to and from model-driven apps in Dynamics 365 between applications. For each environment, you can create up to seven non-interactive user accounts directly from Dynamics

        We need to have the appropriate security role in office 365 and in CRM to create a Non-Interactive user in Dynamics CRM from Microsoft 365 Admin Centre.

• First step is, you’ll create a user account in Microsoft 365 Admins Centre.
• Assign a Licence.
• Wait for user to sync to the CRM environments
• Then in Dynamics 365, select the Non-Interactive access mode for this user account.
• Third give appropriate security role in CRM based on the requirement, so that the Non-Interactive user can be in programmatic API call to CRM.
• Then go back again to Microsoft 365 admin centre and remove the licence for the user, so that it won’t consume any licence for Dynamics CRM Access.

3.2  By Creating an Application user (register Dynamics 365 app Azure-active-directory)

Application user is also a Non-Interactive user which we can use in programmatic API call to CRM. All application users are created with a non-interactive user account, however they are not counted towards the seven non-interactive user accounts limit. In addition, there is no limit on how many application users you can create in an environment.

If you want an app to share a user account as they have the same permission requirements you can give them each their own security key which can have its own expiry date or can be revoked as required. For each application you can give least possible permissions to do what is required (IE the app can have its own user account and security role which only has access permissions required to do its job)

“Introduced in December 2016 Update for Dynamics 365 (online), you can use server-to-server (S2S) authentication to securely and seamlessly communicate with December 2016 update for Dynamics 365 (online) with your web applications and services. S2S authentication is the common way that apps registered on Microsoft AppSource use to access the Dynamics 365 data of their subscribers. All operations performed by your application or service using S2S will be performed as the application user you provide rather than as the user who is accessing your application. S2S authentication means you don’t need to use a paid PowerApps user license when you connect to Common Data Service environments. There is no license fee for the special application user account you will use with S2S authentication. However, there are limits to the number of requests the application user account can call. With S2S authentication, a special unlicensed application user account is created and includes information about your application registered with Azure Active Directory (Azure AD). Rather than user credentials, the application is authenticated based on a service principal identified by an Azure AD Object ID value which is stored in the application user record. The application user is associated with a custom security role which controls the kinds of data and operations the application is allowed to perform.”

3.2.1 Creation of Application User

Prerequisite:

• The user who is registering the application must have a user account with System Administrator security role and the global administrator role for the Office 365 subscription.
• An Azure subscription for application registration. A trial account will also work.

Steps to create Application user

3.2.1.1                Create an application registration in Azure Portal

https://docs.microsoft.com/en-us/powerapps/developer/common-data-service/walkthrough-register-app-azure-active-directory#prerequisites

• Sign in to the Azure portal using an account with administrator permission. You can also access the Azure portal through the Office 365 Admin center by expanding the Admin centers item in the left navigation pane, and selecting Azure Active Directory.
• In the Azure portal, select Azure Active Directory in the left pane and select App registrations and click on New registration. 

• In the Register an application page, enter your application's registration information: 

• On the app Overview page, hover over Application (client) ID value, and select the Copy to clipboard icon to copy the value as you’ll need to specify this in your application’s authentication code or app.config file where appropriate.
•  
• Select Manifest tab, in the manifest editor, set the allowPublicClient* property to true and click on Save. 
•  
• Select API permissions tab, click on Add a permission.
•  
• Select Dynamics CRM under the Microsoft APIs tab
•  
• Click on Delegated permissions and check the options and click on Add permissions.This completes the registration of your application in Azure Active Directory.
•  

3.2.1.2                Create an Application user in Dynamics CRM.

• Browse to your Dynamics 365 instance you want this to access
• Go to Settings > Security > Users
• On the view selector, select “Application Users” and then select New
•  
• On the create new user form, if not already selected change the form used to “User:application user” 
•  
• Create the New User•    Application ID: This will be the Application Id of the registered Azure app and that you took note of earlier•    Primary Email: Give it an email address
•  
• •    Full Name: Give it a full name
• •    User Name: Give a appropriate username
• After the user is created, we can use this as a normal user accounts in integration code any third party connector (MuleSoft, SAP connector) it will need to be given a security role, this can be either one of the out of box security roles or my recommendation is to create a security role that just has the permissions required for the app to function as required.

3.2.1.3                Code Example using the above created application account

I will show you the method of authentication using the Dynamics 365 web API and a C# console app: Note, this uses “Microsoft.IdentityModel.Clients.ActiveDirectory” which I added via NuGet

using System;
using System.Threading.Tasks;
using System.Net.Http;
using System.Net.Http.Headers;
using Microsoft.IdentityModel.Clients.ActiveDirectory;
namespace ConnectToDynamics365CE
{
    class Program
    {
        static void Main(string[] args)
        {
            //enter in the url for your Dynamics 365 online instance below, for the way i’ve coded it make sure it ends with “.com/” also you will probably want to store this as a variable (not in the code) rather than hard coding these in for deployment automation purposes
            string D365CRMURL = “https://yourcrm.crm.dynamics.com/";
           //this will be the query you will be submiting to the API, for the instance defined by the URL above for example purposes I am just querying top 2 contacts
            string query = “contacts ?$top = 2”;
            //create a string for your applicationID and Secret key you will probably want to store this as a variable (not in the code) rather than hard coding these in for security and deployment automation purposes. You can also use key vault feature to encrypt your connection string which I will not cover in this blog
            string applicationId = “applicationID”;
            string secret = “Secretkey”;
            // create a string which calls the Dynamics 365 api using the above variables and stores the response: you don’t need to store it as as a string you could deserialise the response json to an object ect
            string D365response = QueryDynamics365API(D365URL, query, applicationId, secret).Result;
        }
        public static async Task QueryDynamics365API(string D365CRMURL, string query, string applicationId, string secret)
        {
            // this is taking the Dynamics 365 URL and adding the API url bits
            string api = D365CRMURL   “api / data / v9.1 /”;
            //This thing I found is quite cool, you send a request to get the authorisation URL from the Dynamcs 365 instance API you want to connect to, although it does have an issue which I will explain in next comment
            AuthenticationParameters ap = await AuthenticationParameters.CreateFromResourceUrlAsync(new Uri(api));
            //The ADAL (Azure Active Directory Authentication Libraries) this uses (V4) is much stricter in regards to authentication url you can use, the request to get the auth url done just before returns the url with “/oauth2/authorize”appended which if you send a request for a access token using v4 with this appended it will return an error, hence the below line of code removing “/oauth2/authorize” from the url
            ap.Authority = ap.Authority.Replace(“/ oauth2 / authorize”, “”);
            //creates Client credentials using the applicationId and Secret
            ClientCredential creds = new ClientCredential(applicationId, secret);
            // Authenticate the registered application with Azure Active Directory.
            AuthenticationContext authContext = new AuthenticationContext(ap.Authority);
            AuthenticationResult authResult = await authContext.AcquireTokenAsync(ap.Resource, creds);
            //stores the token from the authResult
            string token = authResult.AccessToken;
            // instantiating the request status and giving default value, this will change if request succeeds. only used for demo purposes
            string requestStatus = “error: “;
            // creates a new http client or web client to send api request
            using (HttpClient httpClient = new HttpClient())
            {
                //adds authorisation using the token generated earlier
                httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue(“Bearer”, token);
                //awaits for response from the HTTP request
                HttpResponseMessage response = await httpClient.GetAsync(api   query);
                //if the response is a success
                if (response.IsSuccessStatusCode)
                {
                    //I’m just setting the request status to success, this can be changed per your requirements such as deserialising into a object ect
                    requestStatus = “success”;
                }
                //this is returing the request status text   the content of the request response
                return requestStatus   await response.Content.ReadAsStringAsync();
            }
        }
    }
}

For more step by step images please find attached document. 

https://1drv.ms/w/s!AlfRGGgtLfHngxzO_3gpGLD4B3jn?e=ENI92h