Tip #1292: Use the Route Case field

In customer service deployments, you can wind up with a bunch of different business processes. Sometimes these processes can conflict. For example:

  • Workflows and flows to route cases created through the user interface
  • Routing rules to automatically route cases created by workflows and auto create rules
  • Auto record creation rules to create cases from emails or other records.

If you don’t design carefully, you can create a process explosion, where multiple redundant processes are acting on the same record, and in some cases fighting each other (such as workflows that move manually created cases to queues running on automatically created cases and conflicting with routing rules).

To help avoid any unintentional process interactions, Microsoft provides a little known field called Route Case. This two option field is automatically set to yes when a case is routed to a queue via a workflow, case, or routing rule.

When you build your flows or workflows to route cases to queues, set a condition that routecase does not equal yes/1. Then your workflow will only route cases that have not been automatically routed.

Note this field is not available via advanced find, but you can see it via FetchXmlBuilder and it is available for workflow check conditions.

Thanks to Paul Way for reminding me of this field.

Tip #1291: Do NOT create Flows

I am slowly dragging myself back to reality and going through the backlog of the tips submitted by our readers after an insane family holiday… (You can drop your tip into jar@crmtipoftheday.com. I can’t guarantee that we will publish the tip but I can promise that if we don’t, I will write to you personally explaining why the tip didn’t make it.)

But enough of that. Today’s tip is from Shidin “D365fanboi” Haridas.


Ok, now that I have your attention, let me complete the sentence.

Do NOT create flows unless you are creating it from a CDS solution.

Why??! Because such flows are ‘solution-enabled’ and can be exported and imported during the solution deployment process and hence, better ALM procedures. Woohooo!!!!

Link to documentation: https://flow.microsoft.com/en-us/blog/solutions-in-microsoft-flow/

Screenshot of a Power Maker environment illustrating how to invoke a menu to add a Flow to the solution

Ok, now what to do with the 50+ flows you have already created in your environment?

Don’t worry, here is an easy way to clone your existing flow into a ‘solution-enabled’ flow, courtesy the great Natraj Yegnaraman.

Tîpp Jäår $0.02 + tax

That tip is a good advice if your flow is a part of a PowerApp that includes Common Data Service (CDS). Think of a flow that is, to an extent, a replacement for the legacy workflow.

Besides Flow becoming part of ALM and other mentioned goodness, there is an additional reason to make flow a part of your CDS solution. When you do so, you will have access to Common Data Service (current environment) connector. Why is it cool? Because you will no longer have to deal with reconnecting your flow after the deployment – it will just inherit the current CDS environment the container solution is being deployed into. There is some other goodness in this connector like combined trigger. Plus it’s faster.

Official documentation is now available.

Cover photo by unsplash-logoNicolas Desmangles

Tip #1290: Configure the opportunity close form

In Dynamics 365 2019 wave 2, you can now customize the opportunity close dialog. You can now turn on wave 2 at the Power Platform Admin Center.

Once you have wave 2, the first thing you need to do is enable the setting on the sales tab of System Settings.

Once this option is set, the quick create form of the Opportunity Close entity will be shown to users instead of the dialog. You can configure this quick create form like any other form in the CDS.

bye bye competitor field

Keep in mind that if you are using a model-driven app (and if you are using unified interface, you are), you need to add the opportunity close entity and the quick create form to your model-driven app. Otherwise you will still see the old dialog.

Tip #1289: Restore, don’t recreate

Today’s tip is straight from Microsoft’s own Ben Vollmer. Have a tip? Send it to jar@crmtipoftheday.com.

Right before you go live in a production environment, some partners reset an instance and then layer their solutions on top of the newly created instance. And the version numbers of solutions as well as the actual solutions installed may differ from the instance before the reset.

Why? Every time you reset an instance, the Dynamics 365 service treats the instance like a brand new instance, which it is.

If you have a instance that you want to maintain all of the exact same solution versions and not have new solutions added to it like would happen for a new customer, you should backup the instance and then copy it. Doing that the Dynamics 365 Service Engineering team doesn’t treat your instance like a brand new one.

More data on Reset and Copy is available on the Microsoft Docs Site.



Cover photo by unsplash-logoMarkus Spiske

Tip #1288: SLA’s and solutions

From the short and sweet department: If you have SLA’s in your solution and the SLA’s exist in the target environment to which you are importing your solution, the SLA’s will be deactivated after you import the solution.

If you activate SLA’s via the user interface, your only option is to activate them one at a time.

Lesson learned — avoid reimporting SLA’s unless they have changed. Consider putting SLA’s in their own solution.

Cover photo by unsplash-logoKate Townsend

Tip #1287: Transition to Unified Interface. Now.

The Web Client is likely to be deprecated by October 2019 with a view to be discontinued a year later

Dynamics 365 Unified Interface Playbook

In the immortal words of Jules:

Oh, I’m sorry, did I break your concentration?

Yes, the legacy Web Client is going away. Want to know more? Head off to Unified Interface Community and read excellent Unified Interface Playbook, Transition Whitepaper, and all other goodness.

You’ve been warned.

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)