Tip #1274: My auto record creation rule isn’t creating cases

Yesterday an old friend stopped me with a question. How old is he? He knows how to update an isv.config file.

He had an email enabled queue set up and incoming emails were being created in the queue, but his auto record creation rule wasn’t turning the emails into cases.

I asked him to check if there were any other records like users that shared the same email address as the queue.

He identified that there was a user with the same email address as the queue, and after replacing the queue address with a unique email, the cases started creating successfully.

So what is happening here

Generally in D365/CDS, a record can be associated with only one queue. The exception to this is emails. An email can be associated with a queue item in both a user’s queue and another queue. By default all users have a personal queue.

So when an email comes in it is matched by email address to the queues to which it should be associated. The user queue gets set first, so the auto case creation rule ignores it in the other queue.

Lesson learned: Don’t give user’s and queues the same email address.

Tip #1273: Microsoft Flow dynamic content experience

When creating a flow, when you select a field in a step, you are normally presented with the dynamic content panel. This lets you select field references from your previous steps or write an expression.

But sometimes when you click on a field you will see a less functional list of parameters appear underneath the field.

This is a less user friendly experience because it can be difficult to figure out which field to select (as you can’t see the full name value) and it’s not clear where to enter an expression.

The reason there are two different experiences is to make the Flow maker experience work on small screen sizes. where you don’t have room to display the full dynamic content panel.

If you are seeing the second experience, maximize your browser window and you should see the full dynamic content panel.

Cover photo by Khaled Reese from Pexels

Tip #1272: A better way to notify

I love my D365 email notifications

said nobody

Recently I spoke at a conference with Dynamics users, and I asked the group of about 50 people who liked their CRM email notifications. Nobody raised their hand.

There are several problems with traditional workflow based email notifications:

  1. Everybody gets too many emails.
  2. Blanket workflow based emails will include some notifications that I don’t care about.
  3. System generated email messages that I can’t control diminish my sense of control.
  4. Users, getting overwhelmed with too many notifications, will ignore or delete them

Alternative options

Fortunately, there are better ways to notify in Dynamics 365. One option is don’t notify and teach your users how to use views and dashboards to see records that they need to be aware of. You can also use activity feeds and set up automatic posts via workflow.

Another approach (currently in preview) is to use relationship assistant and use Flow to create new relationship assistant cards.

These are all great options, but in this post I’m going to show you an approach that I’ve used that lets the user decide what he or she will be notified about.

Notification Subscription Center

In this approach we give users choice in what they are notified about and the way in which they are notified. Want to try this solution out? Download a copy at the TDG Power Platform Bank.

Create the subscription center CDS entity

Create a custom entity called Subscription center. You will need the following components:

  • Standard owner field (who should be notified)
  • Notification type — the way the user will be notified. I chose option set because while initially I just have email and SMS options, in the future I may add additional types of notifications, such as mobile push.
  • N:1 relationship with whatever entities you wish to enable notification subscriptions. You do not have to display the lookup fields for these entities on the form if users will be creating notification subscriptions from the parent record.

Now users can “subscribe” to any record for notification and specify what type of notification that they wish to receive.

Creating the Flow

Now when you want to create a notification, such as notify when an opportunity is won, you would create a flow.

  1. Create a flow that runs on change of the opportunity status reason field.
  2. Check to see if opportunity is won.

3. List subscription center records related to the opportunity where subscription type = email.


4. List subscription center records related to the opportunity where subscription type equals text.

5. Insert a condition step and using the length expression, evaluate if the results of the email list records step has at least one record. If it does, do an apply to each with the value of the email subscription list records step and send an email to them. You will need to get the user record of the owner to get the email address.


6. Do the same thing for the SMS subscribers, sending them a text message via Twilio.

Now users can choose what they get notified about and how they are notified.

Bonus tip

Check out this Flow template to see how to send a weekly digest email of notifications.

Cover image by Daderot [Public domain], via Wikimedia Commons

Tip #1271: Where is my tenant ID?

Every now and then someone from Microsoft may ask you for your tenant ID. In my case it was in relationship to one of the preview programs at experience.dynamics.com insider program.

But what is the tenant ID? First, what it is not:

  • It’s not your D365 environment URL
  • It’s not your D365 evironment ID found in settings/customization/developer resources

It’s your O365/Azure tenant id. This can be confusing because some people (even some Microsofties) have been known to use the terms environment/organization/tenant interchangeably. Remember the excitement around the introduction of “multi-tenant” CRM a few years back? That should have been multi-environment. Learn the lingo:

Environment: a separate instance of D365/CDS. Think dev environment, prod environment, any number of CDS environments you may use with Flow and PowerApps.

Tenant: Your Azure instance–this is what is tied to your domain, and you can only have one tenant tied to a domain. All of your AD users and all of your Azure, Office, and Dynamics subscriptions are part of this tenant. See
https://docs.microsoft.com/en-us/office365/enterprise/subscriptions-licenses-accounts-and-tenants-for-microsoft-cloud-offerings .

So how do I find my tenant ID?

There are multiple places this can be found, but this is the most direct IMO:

  1. Go to portal.azure.com
  2. Click on Azure Active Directory
  3. Click Properties under the Manage section
  4. Your tenant is the Directory ID. Azure gives you a button to push to copy the value

Cover photo by unsplash-logoAlex Block

Tip #1270: Table or view is not full-text indexed

Today’s tip is from Marius Agur Hagelund “Viking” Lind (actually, I’m confused, perhaps it’s Marius “Viking” Agur Hagelund Lind?). Got a tip of your own? Send it to jar@crmtipoftheday.com.

Cannot use CONTAINS or FREETEXT predicate on table or indexed view because it is not full-text indexed

Mean SQL Server

If you’ve ever got this error message it’s probably because you tried searching using the SDK using the contains keyword on a field which isn’t full-text indexed.

For me it was searching for systemusers:

nameSearch.Criteria.AddCondition("firstname",
   ConditionOperator.Contains, 
   searchString);

I got the following nice error message in return, which puzzled me at first

Cannot use a CONTAINS or FREETEXT predicate on table
or indexed view 'SystemUserBase' because it is not full-text indexed.

I tried checking in the system, and found that I could search for names there when I used wildcard characters, and then it dawned on me that all these years of autocomplete, intellisense and helpers have made my lazy and dumb. Using wildcards is not the same as using CONTAINS, which is very obvious if you take a SQL Server 101 course found anywhere, so the solution was as easy as this:

nameSearch.Criteria.AddCondition("firstname",
   ConditionOperator.Like,
   $"%{searchString}%");

But what about the web api? Well, turns out they removed the Microsoft.Dynamics.Crm.Contains action and only use the Contains keyword (api/data/v9.1/systemusers?$contains(firstname, ‘mike d’). That is, unless you want to perform a full-text search in knowledge base articles:

https://docs.microsoft.com/en-us/dynamics365/customer-engagement/web-api/fulltextsearchknowledgearticle?view=dynamics-ce-odata-9

So lesson learned: Stop being a dinosaur and start using the web api.

Viking out.

Cover photo by unsplash-logoDaiga Ellaby

Tip #1269: Oh crap, I lost my app

So you decide to “refresh” your development environment with a copy of your production environment, but too late you discover that copying an environment over another one makes canvas apps and flows created in that environment go away.

What should you do?

Other than kicking yourself for not remembering to back up your app and flow definition, don’t do anything.

When you refresh a D365/CDS environment with a copy of another environment, the flows and canvas apps that were in the environment go away, but within a short period of time you will see a restored copy of the app and flows appear in your environment. The canvas apps will be appended with the word “restored” and the date. Flows that are restored will be turned off.

You will need to share the app again with whichever users should have access to it again.

Tip #1268: Restrict CDS instance creation

With P2 licensing, can you control who can spin up a CDS instance via Azure Active Directory since each license comes with 2 CDS instances? (we don’t want hundreds of CDS instances cluttering up our tenant)

The question from an enterprise business size UG member, generously relayed to us by Jerry “Forever Tipster” Weinstock

Via set-TenantSettings example towards end of the post

David F Yack

tl;dr

How to govern environment creation

Download and install the admin powershell cmdlets as described here. Read more about our cmdlets here.

$settings = @{ DisableEnvironmentCreationByNonAdminUsers = $true }
Set-TenantSettings $settings

Note for PowerApps/Flow customers – If you use the new flag to restrict the environment creation, only tenant admin will have the ability to create new environments.

Personally, I like the suggestion that the default should be Opt-in not Opt-out. Or, as one of the commentators put it succinctly:

How quickly can I change that setting to false

Cover photo by unsplash-logoAlice Achterhof

Tip #1267: Do PowerApps work with Dynamics 365 on premise?

The answer is “it depends.”

It depends on how you define “works with.”

There is no PowerApps connector for D365 on Premise. There is a SQL Server connector, and this connector can connect to on premises SQL databases. This includes the D365 on premise SQL database. So you can make an app that reads directly from your on premise CRM database, but this connector cannot update or create records in a supported manner. And as you long time tip of the day readers know, we don’t recommend doing unsupported stuffunless George says it’s ok.Another issue with this approach is it is likely to be slow–it’s very difficult to get good performance reading from on premises systems from the cloud, and you have to open up external access to your SQL server. Just don’t do this.

The second option is to integrate your on premise environment with the CDS–in effect setting up a hybrid environment where you have a copy of your configuration in the cloud as well as your on premise CRM, and create a bi-directional integration to synchronize data changes between the two environments. This is probably the best option as it would recognize your existing security and record ownership and provide full CRUD capabilities. But this option also carries some potential overhead–you will need to reflect configuration changes in both (at least for the entities that are included in your PowerApps), and there will be potential delay for record changes to synchronize between the two — If salesperson 1 updates a contact phone number in D365 on premise and contact 2 saves the contact on her PowerApp, this could lead to some interesting data conflicts. There will also be licensing implications — your users will need to have at least a P1 license in the cloud to be able to use PowerApps that use the Common Data Service

A third option is to synchronize your on premise CRM data with another type of cloud storage — could be an Azure data warehouse, SQL database, data lake, or any number of other places. These are viable connections for your PowerApp. The problem (like # 1) is with creates, edits, and deletes, as well as reads if security restrictions in D365 on premise need to be honored. If I want a Power BI dashboard or PowerApp that simply display any record from my CRM on premise system, I can replicate the on premise data to Azure and go to town. However, if users create or modify records from the PowerApp or need to be restricted in viewing records following the same logic that CRM on premise security roles dictate, this is not a great option, and you may inadvertently open the proverbial barn door.

My recommendation

Don’t do this. Go all the way to the cloud, not part way. Your Power Platform experience will always be more satisfying if you are using Common Data Service and Dynamics 365.

But wait, you say, we have a bunch of reports and system integrations that we can’t quickly upgrade, yet we want to give our users the value of the Power Platform now. I get that and totally understand that if you have been developing on CRM on premise for years, it takes a while to get some of those components cloud ready.

Maybe you should take option 2 and flip it on its head–instead of making the assumption that all of the users will keep using D365 on premise, what if all the users moved to the cloud, yet you kept D365 on Premise around short term for reporting purposes? That way the users could start benefiting from the cloud and directly connected PowerApps and Flows now, but keep on premise around as a read only replicated reporting environment (while you work to move those reports and integrations to a cloud ready approach (like PowerBI). This would minimize the overhead of the approach, as the majority of the users would simply access D365 online.

Summary

Avoid this if at all possible — go all the way to the cloud. If, for some reason, you need to do this short term, I recommend that you replicate your on premise data with the Common Data Service to enforce appropriate security and make your future cloud migration easier.

Cover photo by unsplash-logoElias Schupmann

Tip #1266: Sign out of Skype when forced to Teams

Anyone have any idea how to log out of Skype when your only option is to “Go to Teams”?

Daryl “Always Raising” LaBar

Why would you need to do that? This is my story. I had two Skype accounts: one from my company and another one from, uhm, a partner. I was signed into Skype as my own account and, after we got upgraded to Teams, I would face “Great news – go to Teams” message every time I start Skype. Didn’t give it a second thought. Until, one day, I received an invitation from the partner to join a Skype call and I had to do that using my partner login. So I needed to sign out of Skype which was not possible because it would kick me straight over to Teams. Which is exactly what Daryl was facing.

Oh man, I wish I could remember exactly the magic combo I used to accomplish that (Skype stuck on the team account and I needed the other one). I used the command line switches plus temporarily blocking sign in url (like disconnect your network adapter).

The Enabler

THAT’S IT!
Go to airplane mode, and when it says trying to sign in, you can cancel

Daryl

Moral of the story: when everything is going down the drain, pretend you are offline.

Cover photo by unsplash-logoPeter Pryharski

Tip #1265: Dynamics 365 for Marketing prevents solution imports

Some Dynamics 365 administrators have found that installing Dynamics 365 for Marketing in their dev environment prevents them from moving their configuration changes to production.

Trigger warning–licensing talk ahead (but trust me, it will be worth it)

To understand why this is, you first have to understand how the marketing solution is licensed. Unlike almost every other Microsoft solution, D365 for marketing is licensed by the environment, not by user.

D365 for marketing is priced based on the number of contacts included in marketing activities over a 12 month period in an environment. This makes the pricing scale based on the amount of marketing that you do (and is very similar to other marketing automation providers), and each environment needs to be licensed for Marketing.

The problem comes when trying to move solutions if the Marketing app is not provisioned in the target environment. Dynamics 365 for Marketing adds dependencies to the appointment and user entities, so you will not be able to move these entities in an unmanaged solution from an environment with D365 for Marketing to an environment without D365 for Marketing.

See the official documentation for how Marketing apps are added.

But wait–we have marketing included in our license

You may have received a free marketing app with your Dynamics 365 Customer Engagement license–congratulations. Just understand that this doesn’t mean you have a license for all instances. When you provision that instance, if you choose to put it in your dev environment, you will also need to license it for production.

See the FAQ about the “free instance.”

Recommendation

If  you receive the “free” marketing app but you aren’t 100% sure if you are going to use D365 for Marketing in production, don’t provision the free app against your primary development or UAT environments–you can now have as many CDS/D365 environments as you want, so if you just want to stick your toe in the marketing pool before you are fully committed to it, spin up a new environment and install your free app there. That will avoid creating unwanted dependencies.

By setting up a separate dev sandbox for marketing and not installing marketing in your core dev environments, you will avoid adding dependencies for Marketing to your core configuration.

Finally, if you find yourself with configuration dependencies because Marketing is installed in dev and not in downstream environments, you will need to manually remove the lookup fields and navigation links from the entities with dependencies before you can move your solutions. Alternatively, moving your configuration changes in a managed solution may work (but then you need to be prepared for the ramifications of managed solutions).

Cover photo by unsplash-logomarc liu