Monthly Archives: April 2017

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.Page.data.refresh(true).then(
function(){
Xrm.Utility.openEntityForm(“<ENTITY NAME>“, Xrm.Page.data.entity.getId());
}
, null);
}

It will do two things:

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

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:

http://www.itaintboring.com/dynamics-crm/dynamics-crm-use-a-workflow-to-set-a-lookup/

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.

 

 

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!