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.

https://youtu.be/GIyzQVP6_Vw

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.

Neutral

  • 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

Tip #1276: Do my Dynamics 365 users need a Microsoft Flow license?

As you move your Dynamics 365 automated process from workflow to Flow, you may be wondering if your users will need to have a Flow license to run the process.

First thing you need to know is that most Dynamics 365 licenses include Flow licenses–the main license type that does not include Flow license is team member.

So let’s say you have users who have Team Member licenses. Can you still use Flow to automate your Dynamics 365 processes?

The answer is “it depends”

Scenarios where no Flow license is needed by the user

If a user is triggering a system Flow, and the Flow is owned by a user who is licensed for Flow, the flow will run. Let’s say you build the notification Flow in tip 1272 and a user closes an opportunity, which triggers a text message to be sent from Twilio. In this example, the user is creating a data condition that triggers a Flow owned by a system administrator or service account that is licensed for Flow. Since a user who is licensed for Flow can create processes that work on create or update of any record in the system (to which their security role has access), organization Flows owned by a Flow licensed user can be triggered by non-Flow licensed users.

Scenarios where Flow license is required

If a user owns a Flow, that user must be licensed for Flow. This means that if George wants a user scope process that runs when a task is assigned to him, George would need a flow license.

If a user is running an instant Flow, such as selecting a record in Dynamics and clicking the Flow button, require the user to be licensed for Flow.

Team flows where the flow runs in context of the user–when a document is uploaded to SharePoint, updated something in Dynamics in the context of the same user–typically require the user to be licensed for Flow and whatever connections are in the flow.

Wrapping up

Most Flows that are system automated processes equivalent to system workflows and plugins running just within Dynamics 365/CDS can be owned by a system administrator or service account and do not require the end users to be licensed for Flow to trigger the process.

If the user runs the flow on demand or owns the Flow, they will need to be licensed for Flow. And remember, Flow is included in most “full” user license types.

Tip #1275: Video guide to PowerApps AI Builder (Part 1)

In this first video in our AI Builder series, we look at the recently announced AI Builder product that is currently in preview. We walk through what it is, whats available, how to create models, and finally how to consume the models in PowerApps.

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 unsplash-logoEdgar Chaparro

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