Originally when Dynamics CRM Online first came on the market, in order for CRM partners to configure or support their clients they would either need to “borrow” one of their client’s login and passwords or the client would need to purchase an additional subscription meant specifically for their partner.
These partner CRM login accounts would then sometimes be shared across many members on the partner team. In some cases I had even seen where a license would be temporarily re-assigned from a regular CRM user (whoever might have been out of the office for the day) to a specific partner account.
There were obvious security, logistic and extra cost issues with this approach. Passwords would be openly shared and communicated over unsecured email communications.
Thankfully, Microsoft provided the solution of the “Delegated Admin”. This way partners are able to access their customer’s Dynamics 365 systems using their own individual unique login without any additional cost to the customer.
Added benefits were if someone on the team were to leave a particular partner organization, their individual access could be withdrawn. The customer will also need to specifically allow their partner access.
Personally, I like to ability to access all my Dynamics 365 Online client systems with one login.
More info about Delegated Admins can be found in this Technet Article.
This particular option works well for support, “point and click” Dynamics 365 configuration, adding users, security roles, etc. However having Delegated Admin access does have specific limitations over a regular Dynamics 365 user account with System Administrator privileges.
The Delegated Admin account doesn’t work when trying to access Dynamics 365 using standard development and configuration tools.
When trying to use a tool (such as the Plug-In Registration Tool), when trying to access Dynamics 365 using your Delegate Administrator login you will be denied access.
This affects pretty much any external Dynamics 365 tool or extension, Plug-In registration tool, XrmToolBox, XrmToolKit, Visual Studio and others.
This limitation now brings us back to our original problems to providing partner access to Dynamics 365.
While not 100% elegant, I have come up with a solution that will not cost your customers any additional license fees and allow developers and tool users access to Dynamics 365 to complement their Delegated Admin access.
The solution is to simply create a “non-interactive” user. Typically a non-interactive user is setup in Dynamics 365 to allow access to the system from integration and portal systems.
Read up on Non-Interactive users on this Technet article.
The non-interactive user cannot login to Dynamics 365, but will have access using any of the external tools:
This will require the setup and configuration of a non-interactive user and will require the management of password updates, etc. However, this option will provide a partner full access to their customer’s Dynamics 365 systems without any additional licensing costs, antibiotics or artificial colors.
I hope you find this tip helpful.