Monthly Archives: April 2017

TCS Tools: How to create code expressions without actually writing a plugin

A few years ago, I developed some code for Dynamics, and, then, just put it aside since I was not able to really figure out what to do with it. However, while I was putting together TCS Tools solution in the last few weeks, it occurred to me that I could probably include that code, too.

The idea there is very simple – what if we could write C#-like expressions/code without having to develop plugins? Problem is, the implementation is not, really, 100% there (and, probably, is never going to get that far), but, then, it does allow some interesting things.

Let’s start with an example – here is a code expression which is configured to run on the “create” of account record:

Let’s see how it works – first, I’ll be creating an account:


According to the expression above, what’s going to happen when I hit “save” button is:

  • The expression will check if main phone has been populated
  • It will recognize that the phone number is there, so it will add that phone # to the account name

Here, I just clicked “save”:


That was easy – it worked. It’ll be more complicated to clearly explain how far you can take it:)

This post will introduce you to the basic syntax

TCS Tools: SetActiveProcess custom workflow activity

SetActiveProcess custom workflow activity which comes with TCS Tools allows you to switch active process for a record to a process of your choice. There were some changes in how business processes work in the Fall 2016 release of Dynamics 365, so you might want to read this article first:

Concurrent Business Processes in Dynamics 365

In short, every record can have more than one active process now, and, whenever a CRM user decides to switch his/her process for a particular record, that change does not necessarily affect other users – they will still be working with the process they have selected for that record.

This is an interesting functionality, and it allows for some new scenarios; however, what seems to be missing is the ability to switch the process for a whole team/department. If two sales people are working in the same sales department, it’s only reasonable for both of them to be using the same process when it comes to the opportunity records, for example. At the same time, marketing department might choose to use a completely different process, but, again, they might want it to be the same for all marketing users.

SetActiveProcess custom workflow activity gives you exactly those options:

  • You can use it in a synchronous/asynchronous workflow to switch active process for a record
  • You can also define a team of users pass and it as a parameter to this activity – it will, then, switch the process for all members of that team

There are some screenshots below..

Here is an entity for which I have two business processes defined, and I’m using a two-option “Server Process Switch” field to trigger the workflow 



Here is a workflow that will start whenever “Server Process Switch” field value is modified – it’s using “Set Active Process” custom workflow activity

Here is how the properties of that custom worfklow activity are set for the first of the steps

A few notes about that last screenshot, btw:

  • Make sure to choose correct process into the “Process” field. Business processes are, basically, workflows, so you’ll have to find it in the list
  • Team is an optional parameter. If you don’t pass it to the workflow activity, it will switch the process for the user which it is running under (that’ll be current CRM user if it’s a synchronous workflow, and that’ll be workflow owner user if it’s an asynchronous workflow)

Here is how the team looks like – there are two users in the team



That’s all there is – nothing else is required.

I just updated my “Server Process Switch” field and set it to “Second”. Then I went to CRM under another user account which is a member of the team, and here is what I see


The process is, now, different (compare this to the first screenshot in this post).

There is one additional piece of this puzzle you may need to know about, though. Since the process is switched on the server side, Dynamics does not pick up those changes on the client side automatically. If you re-open the form on the client side, it’ll work just fine. However, in my example above, if simply created that two-option field, selected a new value, clicked save, and, then, used a workflow to switch the process, I would not notice the change till I re-loaded/re-opened the form.

There is a workaround for that. I just need to use this kind of OnChange javascript handler for my two-option field:

function refreshProcessFlow()
Xrm.Utility.openEntityForm(“<ENTITY NAME>“,;
, null);

It will do two things:

  • It will save the data
  • And, then, it will reload the form

Dynamics 365 Tip: Beware of the Form Order in 365

For a very long time now, Dynamics has been offering the ability to create multiple main forms per entity. Those forms are aware of the Dynamics security, so we can use them to give different users different views into the data. So far so good, there is nothing new there.

However, there is something in Dynamics 365 that I have not noticed before.

Let me ask you something.. As a system administrator, if you open a record for an entity that has more than one form, which form, do you think, will show up when you do either of the following:

  • Click “Form” button in the record screen to update the form?
  • Try to mass-edit the record?

I believe it used to be that, at least for the “Form” button, the form you were using at that time would show up in the form designer. Yet mass edit would use the last form you used for that entity type. I might be wrong, and I have no way of testing it for the earlier version of Dynamics right now, but I’m pretty sure it used to work differently from how it works now.

The form that will show up in both cases is, actually, the form that is on top of the “Form Order” for that entity(I am talking about the “main” entity forms):

Of course there is always another way, at least with the form designer: you can choose the form you want to edit from the customizations area. However, when it comes to the Mass Edit.. Well, beware of the Form Order – it’s a mighty one in 365!

And you will find a bit more info about how to set the form order here..

Dynamics 365: There is a HUGE change in how business processes work

So, yes, there is a change. Before I continue, I wanted to make sure you know what business processes are. If you are not too familiar with them, you might want to do some reading first:

Otherwise, I’ll simply walk you through this change.

In my Dynamics 365 environment, I have an entity which is called “Parent” entity. It’s been created for a different scenario, so don’t bother with the name. What’s important is that there are two business process flows defined for that entity – “First” and “Second”:


I’ll now go to Dynamics and create a new Parent record:

As you can see, this is happening under my account, there is a process flow, so everything looks good. I’ll save the record and will use another user account to see how it looks like there (just for the sake of this experiment, I’ll actually use a different browser as well.. no caching then):


It’s another user now(CRM Admin), but, as you probably expected, it’s the same process flow. So, where is the change that I promised?

Let’s use this last screen to switch the process:


Here is the result – it’s a different process now (remember, we are still under CRM Admin there):


Stop for a second and ask yourself: which process is going to show up under my original “Alex Shlega” account? It must be the same process that “CRM Admin” has set for the record, right? That’s how it used to be, and I would not think twice myself.. until earlier this morning when I saw this:

Under my original account, I’m happily looking at the same record (and I did refresh the page/reloaded the browser), and I am still seeing the same original process!

This is by design, I will explain shortly. But the consequences are.. You can switch the process, but everybody else can still be using a different process. Is it a bug? A feature? It’s definitely a different way to do things (and it is also affecting the API-s, btw. They are still using the same old function signatures, but they are switching processes per user as well).

For the explanation, you have to read through this article published by Microsoft Dynamics team:

Long story short, The Fall 2016 release of Dynamics has introduced the concept of Concurrent Business Processes. That also involved quite a few changes in the underlying entity model; however, the end result is that there can be more than one active process per record. Yet, it seems, every user can now pick the process they are following for each record.

And, for example, if you are still using this technet article for a reference, it does not seem to be valid anymore, since it’s saying that “Each record can have only one business process flow at a time”:



I’ve spent some time trying to find a way we could use SetProcessRequest SDK request to synchronize active business process between different users, and, eventually, it worked. There is a strange problem, though. Usually, this is how we would create IOrganizationService in our plugins:

IOrganizationService service = serviceFactory.CreateOrganizationService(context.UserId);

So, basically, I was simply trying to create IOrganizationService for different users and use those different service instances to execute SetProcessRequest requests for each of the users. It was not working till I moved my plugin to the “Pre-Validate” stage of the plugin execution pipeline. I have no explanation as to why, but, it seems, SetProcessRequest request is using some sort of contextual information that gets locked in the transaction since Pre-Validate runs outside of the database transaction.

TCS Tools:

There is a new Set Active Process custom workflow activity that has been added to the TCS Tools. You can use it to assign the same business process to one or more users per record:

TCS Tools: SetActiveProcess custom workflow activity

TCS Tools: Solution Summary

TCS Tools is a set of components for Dynamics 365 – it’s a work in progress solution, you can find the summary of those components below. Feel free to download it and deploy in your Dynamics instance. Don’t forget to keep me posted on how it works out for you.

In order to deploy the solution, follow this steps:

  • Download managed solution file from here: TCS Tools for Dynamics
  • Import this solution file to Dynamics
  • Open Dynamics default solution(customizations) and add “TCS Expression”, “TCS Lookup Configuration”, and “TCS Number Sequence” entities to the “settings” area (or to the area of your choice), then publish all customizations

Note: there used to be a link to the version of TCS Tools for 8.x here, but that version is no longer supported.

Once the solution has been deployed, follow the links below to find out what’s available there:


Code Now plugin for XrmToolBox

CodeNow plugin has its own home page now:



DISCLAIMER: You can use TCS Tools and Code Now plugin on your Dynamics projects – there are no strings attached. However, if you do so, that means you agree that the author (me) cannot be held responsible for any issues that may or may not occur in your environment due to the use of these tools.

Dynamics 365: Can’t find all parent records that have no child records using Fetch (Myth BUSTED!)

It is an incredibly popular question: how do we find all parent records which do not have some kind of related child records?

  • How do we find all accounts without opportunities
  • How do we find all teams without users
  • How do we find all Parent entity records that have no Child records associated with them

And there is an incredibly popular answer: IT IS NOT POSSIBLE.

Well, it actually is. Although, not in the advanced find. But you don’t have to believe me – I’ll simply show you how it’s done.

In my Dynamics 365 environment, I have created two custom entities: Parent and Child.

The first two (“Another Parent” and “Main”) have child records linked to them. For example:


The last one (“No Children”) has no child records:


So there are a couple of questions we may want to ask in this situation:

  • What are all the parents that have some children?
  • What are all the parents that have no children at all?

The first question is easy to answer using Advanced Find:


Just as expected, there are two parent records.

How about the second question? Can we replace that “Contains Data” filter with “Does not contains Data” and get meaningful results?


Apparently, we can change the filter, but here is what we are going to get as a result:

Wow, it’s empty! I was hoping for a bit better result – remember I do have that “No Children” parent record?

So.. IT IS IMPOSSIBLE, after all, right? No, we are not done yet.

Let’s download that FetchXml from Advanced Find and modify it a little.

Here is the original:

<fetch version=”1.0″ output-format=”xml-platform” mapping=”logical” distinct=”true”>
<entity name=”tcs_parent”>
<attribute name=”tcs_parentid” />
<attribute name=”tcs_name” />
<attribute name=”createdon” />
<order attribute=”tcs_name” descending=”false” />
<link-entity name=”tcs_child” from=”tcs_parentid” to=”tcs_parentid” alias=”ad”>
       <filter type=”and”> 
           <condition attribute=”tcs_childid” operator=”null” />

And here is the modified version:

<fetch version=”1.0″ output-format=”xml-platform” mapping=”logical” distinct=”true”>
<entity name=”tcs_parent”>
<attribute name=”tcs_parentid” />
<attribute name=”tcs_name” />
<attribute name=”createdon” />
<order attribute=”tcs_name” descending=”false” />

   <filter type=”and”> 
           <condition entityname=”tcs_child” attribute=”tcs_childid” operator=”null” />
    <link-entity name=”tcs_child” from=”tcs_parentid” to=”tcs_parentid” alias=”ad” link-type=”outer”>

I have highlighted the modified part for you. First, it has to be an “outer” join. Second, that “filter” condition has to move up, and, yet, I have also added entityname attribute to the condition.

That’s fully compatible with the FetchXml schema, btw. If you are interested, have a look at the schema:

The next step is a bit tricky – I need to test that FetchXml. I can’t easily put it back into CRM to replace an existing view, for example. However, Dynamics 365 comes with WEB API which actually allows us to run fetch query(did you know?)

Once you have logged into Dynamics, you can construct this kind of url:


So, let’s try it. For the original FetchXml, here is what I got:

Now here is what this whole post was for – I am going to try modified FetchXml. And, here we go:

In other words, it’s absolutely possible to use FetchXml for this kind of “not exists” conditions. We may not be able to create views in Dynamics, but we can easily use it to develop plugins, reports, custom applications.. or simply to run those fetch queries through Web API if we do want the results quickly.

PS. By the way, the credit for this method goes to Aiden Kaskela. If you are curious to see where it all started, have a look here:




Dynamics CRM (TCS Tools): Use a workflow to update related entities

If you read my previous post, you know how you can use TCSTools Lookup Setter custom worfklow activity to find a lookup value using a fetchxml query:

Let’s imagine a different scenario. What if you had an account and related contacts, and what if you wanted to push a field value you just entered on your account record to all of those contacts?

That is also easy to do, you just need to read that post above, and, then, think of it in reverse.

Here is what you would need to do:

  • User Advanced Find to create FetchXml that will return all contacts related to a particular account (pick any account when doing it)
  • Download FetchXml from the Advanced Find
  • Replace the id of that account in the parentcustomerid condition with “#accountid#”
  • Create a Lookup Configuration record (it’s the entity which comes with TCS Tools), and make sure to use “Fetch Result” for the direction. That will instruct the custom workflow activity that it actually need to update the records returned from the fetch (and not the record for which that worfklow has started)
  • Create a workflow for the account entity, and use Lookup Setter (paired with the Lookup Configuration created above) to update all those related contacts

Below are a few screenshots.

Here is my lookup configuration record:

  • Update direction = Fetch Result (meaning that fetch result records will be updated)
  • Fetch Result Attribute is set to “tcs_accountnumber” (this is the field that’ll be updated)
  • Entity Attribute is set to “accountnumber” (this is the field on the account record that will be used to update fetch result records)
  • Finally, FetchXml is constructed is such a way that it will get all the contacts where my current account record is added as a parent customer


Here is the workflow that will update related contacts – we are only interested in the highlighted step right now. Two other steps are interesting as well, but I will explain what they do in the next posts.

And, of course, just so you could see how that step is configured, here is the last screenshot:

That’s it, really. What this workflow will do, it will push account number updates from the account record to the related contact records (where I have a custom field called “tcs_accountnumber”).

By the way, did you notice something? You don’t really need to define a relationship between two entities to use this custom workflow activity. As long as you can define your fetchxml in such a way that it will return required records (maybe based on the email address.. based on the city name.. or simply based on the date interval), you can use this custom workflow activity to update all those records.

Just keep in mind that you probably don’t want to update thousands of records every time – performance can easily become an issue for this kind of mass updates.



Dynamics CRM (TCS Tools): Use a workflow to set a lookup

It happens sometimes that we have a Parent and Child entities in Dynamics, and we need to link a child record to a parent record. Which seems to be a simple task unless, of course, we need to do it automatically. That’s exactly when we’ll know that we have an unexpected problem – if we wanted to use a workflow, there would be no out-of-the-box functionality that would allow us to do that.

Things can quickly get worse if it turns out we need to apply more complex rules when looking for a parent record. And what if there are duplicates? Arghh..

Here are just a few examples of that kind of relationship:

  • Account and Parent Account
  • Account and Primary Contact
  • Case and Customer

Every now and then we would have some unusual situation where we would have to put a few Child records to Dynamics, we would know that there are Parent records, and, yet, the relationship would be more complicated.

For instance, we might have a few parent accounts with the same name, and we would have to choose the most recent one. Out-of-the-box Dynamics workflow are not offering this kind of lookup functionality, but this can be accomplished using a custom workflow activity.

If that’s why you are reading this post, my TCS Tools solution for Dynamics CRM might be of some help. Here is how it works.

1. Import the solution to Dynamics. It is an managed solution, so you will be able to remove it.

2. Use advanced find to create a Lookup Configuration record (see complete walk-through below)

3. Create a worfklow on the Child entity that will be using TCS Tools:Lookup Setter activity to set parent lookup attribute based on the Lookup Configuration you just defined


Let’s imagine the following scenario for an Account and Contact entities:

in our Dynamics organization, we have account and contact records. There is “Account Number” field in the Account entity that’s been populated already:

That’s an out-of-the-box “accountnumber” field, although it is not available on the form by default, so I just added it there.

Also, let’s say there is a similar field in the contact Entity, and I actually had to create such a field since it’s not there out-of-the-box:

The schema name of this field is “tcs_accountnumber”. We’ll need it a bit later.

In our scenario the requirement is:

when adding a new contact, we will know account number, but we won’t know account name. What we need is to create a workflow that will correctly populate “Account Name” lookup in this situation.

So, first, let’s create our Lookup Configuration record. In order to do that, we will need to prepare Fetch Xml first. It’s easy to do using Advanced Find – I will open Advanced Find, define the filter, and will use “Download FetchXML” button to get the xml:

Notice how I put tcs_accountnumber in the filter there – you can put anything, it’s just for convenience(you’ll see in a second).

Here is my downloaded FetchXML:

<fetch version=”1.0″ output-format=”xml-platform” mapping=”logical” distinct=”false”>
  <entity name=”account”>
    <attribute name=”name” />
    <attribute name=”primarycontactid” />
    <attribute name=”telephone1″ />
    <attribute name=”accountid” />
    <order attribute=”name” descending=”false” />
    <filter type=”and”>
         <condition attribute=”accountnumber” operator=”eq” value=”tcs_accountnumber” />  

I have higlighted the part I’ll need to modify. “Lookup Setter” custom action will be running for contact record in this scenario. It will go over all the attributes of the current contact record, and it will try to find the following tags in the FetchXML:

#contact attribute schema name#

If it finds a tag, it will replace it with the actual value of the attribute.

Therefore, here is what we should use for the Lookup Configuration:

<fetch version=”1.0″ output-format=”xml-platform” mapping=”logical” distinct=”false”>
  <entity name=”account”>
    <attribute name=”name” />
    <attribute name=”primarycontactid” />
    <attribute name=”telephone1″ />
    <attribute name=”accountid” />
    <order attribute=”name” descending=”false” />
    <filter type=”and”>
         <condition attribute=”accountnumber” operator=”eq” value=”#tcs_accountnumber#” />  

From here, there are only a few steps left.

Let’s create our Lookup Configuration record (I’ll be using Advanced Find for this):



There are a few things on the last screenshot you need to be aware of:

  • Give that record any name you want, just make sure you know what it means
  • Use FetchXml created earlier fort he Fetch Xml field
  • Fetch Result Attribute is the schema name of the attribute that will be used to populate the target field
  • Target Attribute is self-explanatory. That’s what this whole thing is for, really

Once I have Lookup Configuration record, I can proceed to create a workflow:

This is a real-tie workflow – it does not have to be, but it’s more convenient when parent account is set right away.

It will run when a contact record is created or when Account Number field is modified on the contact.

And it won’t do anything (there is a condition in the first line) if Account Number field is empty.

Finally, if it runs and if it gets through that first condition to the TCS Tools:Lookup Setter custom workflow activity, it will need to know which Lookup Configuration to use, so I’m going to set the properties of that step:

That’s it.. Now I’ll save everything and activate the worfklow.

Let’s see what happens when I create a new contact – remember the very first screenshot in this post? I’ll be using the same 20170101 account number for my contact, but I’ll leave “Parent Account” field empty:


And, with that, I’ll just click “Save”.

Here we go.. I knew contact’s account number, and that’s what I put into the contact record – that workflow has done all the rest. It found the account record and populated “Account Name” field on the newly created contact.

From here, I might add more conditions to the Fetch XML if I wanted to define more elaborate rules. I might also use it in combination with the data import jobs or to fine-tune various data migration jobs. All of that without having to write any more code. Mission accomplished!

Dynamics 365: Editable grids and autosave

For a little while now, Dynamics has been offering editable grids. Having this functionality in Dynamics had been a dream for many of us – it makes a lot of things so much easier. After all, we can finally provide that great user experience where users can edit everything they need on the same screen.

However, there was a discussion recently where somebody mentioned that autosave does not work for editable grids:

And indeed, it does not. You can change something in the editable grid, close the form, and you will lose your changes as a result. Which is different from how it works for other, non-grid fields.

I did a bit of research and found this article:

Some important points to consider for the OnSave event:

  • If a user edits multiple columns of the same record in sequence, the OnSave event will only be fired once to ensure optimal performance and form behavior compatibility.
  • Editable grid and the parent form have separate save buttons. Clicking the save button in one will not save changes in the other.
  • Editable grid does not save pending changes when navigation operations are performed outside of its context. If the control has unsaved data, that data may be lost. Consequently, the OnSave event may not fire. For example, this could happen when navigating to a different record using a form lookup field or through the ribbon.
  • Pressing the refresh button in the editable grid causes it to discard any pending changes, and the OnSave event won’t be fired.
  • Editable grid control does not implement an auto-save timer.
  • Editable grid suppresses duplicate detection rules.

So.. it seems to be a bug? It’s sort of difficult to call it a feature, but, on the other hand, it’s definitely a known bug.


It seems there is no workaround, at least there is no supported workaround. Problem is, editable grid does not expose any sort of “save” or “set selection” method, so there seem to be no supported way to force it to save the updated data.

Check your plugin code, or here is what you’ll see: There should be only one owner party for an activity

There is an interesting error I’ve never seen before that can now happen in Dynamics whenever you are deleting a service activity:

Log file does not have a lot of information, but there is a clue:

[Microsoft.Crm.ObjectModel: Microsoft.Crm.ObjectModel.SyncWorkflowExecutionPlugin]
[75200d82-9f20-e711-8118-480fcff4b171: ]
Starting sync workflow ‘Assign SA’, Id: 6f200d82-9f20-e711-8118-480fcff4b171
Entering AssignStep1_step:
Sync workflow ‘Assign SA’ terminated with error ‘There should be only one owner party for an activity’

<OriginalException i:nil=”true” />
<TraceText i:nil=”true” />

The workflow mentioned above is extremely simple:

You see, the workflow is simply reassigning a case to another user when the service activity is being deleted.

You may ask why would I need such a workflow.. Can’t think of any particular reason, but it’s a simplified test for a more complicated scenario which I will describe below. For now, let’s just summarize what’s happening there:

  • We are trying to delete a service activity
  • That starts a workflow
  • That workflow is re-assigning a “regarding” case to another user
  • And, then, an error occurs

I cannot explain why would this error happen, though I’m assuming Dynamics is trying to do something behind the scene and it can’t because, maybe, that SA record is locked in the “delete” transaction?

Either way, the end result is, we are seeing a rather confusing error message: “There should be only one owner party for an activity”

Here is a real-life scenario, though:

  • Imagine there is an on-delete plugin that recalculates duration fields on the account/case whenever a service activity is being deleted
  • Imagine that plugin is retrieving case record, modifying duration field, and, then, just pushing it all back

This is not the right technique – we should not be pushing all attributes back, but it happens sometimes. The end result is that the “owner” attribute of the case entity is pushed back as well.

Now, we know that “AssignRequest” has been deprecated by Microsoft, and we are now supposed to just update the “OwnerId” field directly:

However, it seems we are also not supposed to update it when we don’t need to:) In the above example, that’s exactly what’s happening though, and, it seems, it can lead to exactly the same error as it happened here: