Tip #1286: Synchronize your watches


If you’re using CrmServiceClient and getting what seems to be a valid connection but cannot really use it because of the “The user authentication failed!” error, check the servers’ clocks in your infrastructure.


I have some perfect reasonable code deployed in Azure and that code has been humming along, talking to Dynamics 365 On-Premises for as long as I can remember. The code uses Xrm Tooling (yes, from time to time we listen to our own advice). Then one day – kabrakeeboom! – we get the log full of the following messages

Message: The user authentication failed!
StackTrace: at Microsoft.Xrm.Tooling.Connector
.CrmServiceClient.Execute(OrganizationRequest request)
blah-blah, our code

Quick check with the customer’s technical support – nothing has changed, no updates were installed on any of the servers. Sample code to troubleshoot:

string cs = "bleugh";
using (var client = new CrmServiceClient(cs))  
    if (client.IsReady)
        var foo = client.Execute(new WhoAmIRequest()) 
                        as WhoAmIResponse;

Here’s the kick: IsReady is true and GetMyCrmUserId returns a valid value (probably cached) but Execute spits out “The user authentication failed”. Adding logging showed that coveted token gets invalidated immediately after the connection is made. It gets better: XrmToolBox would successfully connect to the instance as well but any attempt to use anything pops up “The user authentication failed!”

Don't look at our crotches while we synchronize our watches!

I’ll spare you the pain of ADFS debugging.

You know how they always synchronize watches in the action movies (there is even a song about it)? Now I know the reason.

ADFS server had its clock synchronized with the time service that was drifting over the time. Into the future. Once the drift was over 2 minutes, ADFS continued to issue tokens but they now were invalid the moment they left the server. Why nobody noticed and UI didn’t break? Because Dynamics 365 server was drifting as well, perfectly in sync with ADFS.

Tip #1285: Dynamics Divorce

We are selling part of our business and want to split our environment into a separate environment and move to another D365 tenant. How do I do that?

splitting up


Here’s my recommendation for splitting on environment into two:

  1. Identify the customer and related records that are shared by both groups. These are the joint custody children and pets in the D365 divorce. Flag these records (can use a custom field).
  2. Start by separating the two groups into different business units—this lets you separate the records before deleting them out and test to ensure that the split is as clean as possible.
  3. Make a copy of the environment.
  4. In the target environment, delete the records in BU1 except for the records flagged in step 1—I would do this first because you can go back and redo if you mess up. Then test.
  5. In the source environment, delete the records in BU2 except for the records flagged in step 1.
  6. Work with Microsoft support to move the new environment to the other tenant

Other considerations

  1. Integrations need to be adjusted to only integrate the appropriate records
  2. Third party ISV solutions may need to be reconfigured/updated and licensing adjusted—the new company will need to license D365 and any third party solutions included.
  3. Under the new licensing model, Microsoft is enforcing functionality via licensing. If, for example, configuration includes field service but the new organization won’t be using field service and users aren’t licensed for it, you will likely need to remove some Microsoft solutions after you copy the environment.


Separate the data and copy before moving. This minimizes the risk as it can be tested and rolled back before burning the ships.

Tip #1284: Forms Pro and how to be unprofessional

Here at tip of the day we are quite excited about Forms Pro. If you don’t know, Voice of the Customer will be deprecated in one year, and so you really should be reading Megan’s blog and getting familiar with Forms Pro.

You sign in to Forms Pro at formspro.microsoft.com, but once you do, you may notice that your browser URL changes to forms.office.com, and you will see your regular (non professional) forms mixed in with your Forms Pro forms.

So what is the difference? There are mainly two:

  • Forms is part of your Office license, Forms Pro is part of your Dynamics 365 license. Enterprise licensed customers get 2,000 Forms Pro responses per month. Additional responses may be purchased in chunks of 2,000.
  • Forms Pro responses are stored in the common data service, Office Forms responses are not.

So once you sign up for Forms Pro, what if you have a survey or quiz that you wish to use but you don’t need or want it to be a pro form? Say you are doing a quick survey of your colleagues to see what kind of cake they want at the holiday party. Do you really want that to go into the CDS or take up some of your Forms Pro response quota?

You can still create non-pro forms (unprofessional forms???) by clicking the settings gear and clicking “show button to create classic Form.”

Cover photo by unsplash-logoRobert Bye

Tip #1283: Too many birthdays

Outlook has a fantastic feature that reminds you when your contacts have a birthday. You will see a repeating appointment on your calendar that notifies you about their birthday.

The problem with this feature is if you frequently connect to different Dynamics 365 environments, such as a trial environment, and you want to demonstrate Outlook/Exchange synchronization.

If there are contacts in the environment with a value in the birthday field and you synchronize Outlook contacts with that environment, you may start seeing birthday reminders for people who don’t exist–the sample data in your demo environments.

If you have phantom birthdays appearing on your calendar, here is a sure-fire way to clean it up:

  • Navigate to your Outlook calendar
  • Search for “birthday”
  • Delete the results (except for your mom)

Tip #1282: Dynamics 365 customization & configuration using the Power Platform

In this video, we show how and where to find the typical items that Dynamics 365 consultants worked with to configure and customize Dynamics 365 applications using the Power Platform.

We will demonstrate how to find and change common tasks like administrative and business settings, security roles, email configuration and more.

In addition, we will demonstrate how to access the Power Platform equivalent customization tools for doing things like adding and modifying fields, entities, forms, and views now done in the Power Platform.

Give us your feedback, all of it: good, bad, and ugly, I’m sure we can take it. Suggest new topics either in comments or by sending your ideas to jar@crmtipoftheday.com.

Don’t forget to subscribe to http://youtube.com/crmtipoftheday.

Tip #1281: Video guide to PowerApps AI Builder (Part 2)

In part 2 of our working with AI Builder series (part 1), we examine how to create and use the Binary and Text Classification AI models. We walk through t how to build the models, as well as how to consume them in both Model Driven Apps and Flows.


Give us your feedback, all of it: good, bad, and ugly, I’m sure we can take it. Suggest new topics either in comments or by sending your ideas to jar@crmtipoftheday.com.

Don’t forget to subscribe to http://youtube.com/crmtipoftheday.

Cover photo by Matan Segev from Pexels

Tip #1280: To split, or not to split, that is the question!

The subject of today’s tip is highly debatable but Eric Regnier did do justice to it. (Want to start a discussion of your own? Email your tip to jar@crmtipoftheday.com)

In many implementations particularly complex ones, often comes a situation to determine if the same entity should be used for the different “types” (or categories). Say an insurance company implements claim management, there are multiple types of claims, each with their own set of fields and separate business logic/requirements. What do to? One claim entity for all or split into its own entity? Here are some quick pros/cons to provide some guidance.

Some assumptions to support the pros/cons

  • Entity in question is complex (>100 custom fields)
  • Entity has a high chance of evolving (especially in Agile methodologies)
  • Entity is a core/important entity of the system

Pros if split

  • Ability to segregate privileges per entity and therefore, have a simpler and more flexible security model. Although might be possible to satisfy requirements if it were one entity, security becomes more complex, e.g. using field level security (which has perf impact amongst other things.)
  • Ability to segregate customizations (plugins, workflows, etc) per entity aka separation of concerns. E.g. no extra lines of code to determine which logic to execute based on the type. Some performance gain; can scale and scope plugins/workflows/Flows/etc to execute on the exact type.
  • Less risk of regression. Changes occur only on the respective entity, and not touching the other types.
  • Leaner forms per entity. Don’t have to create separate forms or one form with JavaScript to auto-switch based on type.
  • Performance on searching. If one entity for all types and many fields require searching, might have performance impact. From my experience, I try to limit searchable fields (quick find) to no more than 10.
  • In database terms, entity model becomes more “normalized”.  Easier for developers and end-users (e.g. in Advanced Find) since only the corresponding fields are made available. Don’t have to think which fields are for which type.
  • If entity contains a lot of data (>1M), in split scenario, data is split and each entity can have its proper indexes.     
  • Might be cases where sub-types or even sub-sub-types are needed which make the entity model even more complex if it were one entity.


  • Reporting can become simpler or more complicated depending of the case. If split, can target specific type without additional filters on every report/view.
  • No impact on global/relevance/categorized search. All entities can be configured accordingly. Search at the entity level however will only get results from the entity selected.

Cons if split

  • On forms, dashboards and views/charts will have separate sub-grids per entity.  If required to see records in one sub-grid, then custom web resource or canvas app is required.
  • If same logic is required on each type, then will have to copy or rely on JavaScript/code not to duplicate the logic. For example, show/hide field on form with business rule. Will require the same business rule on every type unless a common JavaScript function is done (requires a developer).
  • There is no concept of inheritance in CRM/D365 CE, so if many fields are the same, will have to recreate the fields in every entity. Developer/customizer will need to be vigilant to ensure the datatype and names matches exactly.

Tîpp Jäår $0.02 + tax

Splitting entity is one of my favorite techniques, especially when it comes to security. But I knew I used it for something else in the past… Lo and behold, “how to update a record without modifying the modifiedon” or Keep your pants on and timestamps intact.

Tip #1279: Select your region in multi-geo deployments

Today’s tip is from Moez Tounsi (and if you have a tip of your own, email to to jar@crmtipoftheday.com).

It is about Dynamics 365 Administration Center (yes, it’s still there – t.j.). Let’s say we have a tenant in EMEA (crm4) with multi-geo activated in it and a couple of Instances in NA others are in EMEA.

The Administration Center for Dynamics 365 (if login to the Organization List) will look like this.

Let’s say you need to create an organization in the NA DC you select the Org to configure, most of the time this will fail. Then I selected an org in the NA I noticed that the Solution button disappeared and only appeared in the EMEA ones.

I switched the region I needed to work from and TaDa!

I am able again to edit my instances in NA and create new instances in NA. Basically,

Correct region needs to be selected before performing administration tasks on a new or existing instance in that region.

This also applies to PowerApps Administration and the CDS (apparently in a single tenant, your CDS is region related).

Cover photo by Artem Beliaikin @belart84 from Pexels

Tip #1278: This message never ends

Sometimes even the best of the best could be puzzled by the mysterious innerworkings of Dynamics 365/CDS SDK. Tanguy “The XRM Toolbox” Touzard was not having a good day…

For one of my projects, I’m using ReassignObjectsOwnerRequest SDK message to move records from one team to another team. When this request should last more than an amount of time (let say, more than 10 minutes but I did not figure yet what is the exact number), the request never ends on my program.

If I kill the program, then try to reassign records by hand (using Reassign records button in user form), it’s super fast (two seconds or so) and I can then delete the team (which means the reassign process had completed, even if it seems not having ended, from the SDK perspective).

Shan “Jeep Jedi” McArthur, Principal PM at Microsoft, explains:

CDS/CRM 9 is now hosted in Windows Azure and we have Azure firewalls between you and our web servers (as well as between our internal services too). Azure will drop long running connections that exceed 4 minutes. The client application will see this as a dropped connection, but on the server, things continue chugging along until the work completes or errors out. Solution imports are notorious for being long running and that is why we have an async pattern for them and have moved our larger solutions to using async instead of sync. I think this explains the issue you are noticing.  The work completes quickly when you do it from the UI because the heavy lifting was done by the request that your original tool sent in and there is little or no work remaining.

Tîpp Jäår takeaway (or take out when in America)

  • Avoid long running synchronous operations if you can
  • Evaluate the scope of your operation (e.g.
    ReassignObjectsOwnerRequest could be massive) and do it “by hand” (e.g. reassign by entity)
  • Detect dropped (idle) and timed out connections in your client code
  • For non-critical operations, keep your fingers crossed and hope it’ll complete just fine (like it did for Tanguy)

Have a tip about how to deal with long running processes? Email it to jar@crmtipoftheday.com.

Tip #1277: Alternative connector to trigger Flow from Dynamics 365

I’ve always been a fan of webhooks. In fact, I even manage to mention them twice in my rare crystal ball post for developers.

Today’s tip is a good reminder from Stefan Strube that webhooks are not only a solid way to launch your code in Azure Function but also can be a good alternative to Microsoft Flow connectors.

In short, HTTP trigger in Flow gives you a unique URL that can be easily wired as a webhook endpoint. Unbundling the execution context could be tricky but the possibility is there.

Since Stefan tipped the subject, Dynamics 365 connector has been deprecated but we now have two Common Data Service connectors: “traditional” CDS one as well as Common Data Service (current environment), that carries the notion of the environment without the need to reconnect when deploying (as part of the solution).

Why would you want to use a webhook as opposed to a nice and easy-to-use CDS connector? Flows triggered by CDS connectors are asynchronous by nature while webhooks can be configured to execute synchronously giving you an opportunity to rollback the entire pipeline. Careful though – Flow performance as such is not guaranteed, I would exercise extreme caution when inserting a flow as part of my pipeline.

Cover photo by rawpixel.com from Pexels