A new version of Microsoft’s Unified Service Desk (USD) for Dynamics 365 has recently been released, V3.0. This new version contains a feature to run CreateEntity actions asynchronously. I will explore this new capability in this post.

The CreateEntity action is used to create records in Dynamics 365 from USD. This can be used for many purposes, if you haven’t used this action before you can find an example here. In my example I create a phone call and then load the newly created activity record. This is possibly a great example of when we’d want the CreateEntity action to run synchronously! As I will need to capture the GUID of the newly created record to allow me to open it.

But there are times when all I want to do is insert a new record and waiting for the create action to complete will therefore needlessly add an overhead. Granted the impact of a CreateEntity action can be quite minimal. Although I did recently discuss the need to create records in an entity with many millions of rows and multiple alternate keys. An insert to a table like that could have serious performance implications.

To explain this action, let’s consider a different example. In my application I also create “audit” records. These simply contain details of the session and are created when I close sessions. In this example I would quite happily fire and forget the create action, as I don’t need to interact with the newly created records.

To alter my CreateEntity action to run asynchronously I simply add “RunAsync=True” to the action. As shown below.

Great so now my CreateEntity action will run without potentially slowing the start of the next action.

But I would like to point out the important difference in the results. Below you can see a similar CreateEntity action without the “RunAsync=True” setting. Notice that the results column contains the GUID of the record it just created.

Now lets look at the results from my action using “RunAsync=True“. Below you can see that the results column does not contain the GUID of the newly created record. Also notice that the duration is “significantly” smaller. Actually in my application I doubt anyone would notice this change! Although in other examples the create might take longer or if you need to execute large numbers then the impact would be noticeable.

One final observations, Microsoft’s technical details contain the following note. It explains that the associated sub-actions and subsequent actions do not wait for the CreateEntity action to complete. Perfect, as that is exactly what I needed. It is suggested that you could use an ExecuteOnDataAvailable action if you need to wait for the create. That would certainly work, although I would suggest a better approach would be simply not to use “RunAsync=True“!

Even though the performance gains maybe minimal I will be adding “RunAsync=True” to all my creates that don’t need interaction with the created record. Multiple small gains can really help to make the entire solution feel more responsive. Enjoy.