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” />
</filter>
</entity>
</fetch>
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#” />
</filter>
</entity>
</fetch>
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!