MrDave's (David Yack) CRM Blog!

This is the 2nd part following up on my prior blog post that discussed the challenge in using values with WaitFor in a workflow.  In this post, we are going to explore tackling this without custom code, just using a custom entity to store the value we want to save a copy of.

To keep this generic, I'm going to use a custom entity called WF Workspace (crmbook_wfworkspaces) - think of it as a scratch pad to use while your workflow is running.  We are going to add a few attributes to this custom entity that we will use to store our values.  The following are the properties we are going to add:

crmbook_stringvalue , crmbook_intvalue and  crmbook_moneyvalue

Basically one for each data type we want to be able to store in our workspace.  The reason the type matters is we want to be able to do this using only the workflow editor and without any custom code (see Part 3 for custom code method)  The workflow editor will only allow assignment of values of like data types so that is why it's important to have the various types of attributes.

There's really no reason to add these fields to the form other than it makes it a little easier to set the value later in the workflow editor.  The workflow editor puts all fields in an Additional Fields tab if they aren't allocated to the form.  Keep that in mind if your ever trying to set a value of an attribute and can't find it - check the Additional Fields tab!

Now, let's create a new workflow and have it be triggered on Create  of Account.  Our first step in the workflow should be to save the value of Account.Name to the wf workflowstate entity.  To do this we are going to add a Create step to our workflow and set the values as you can see below.

On the set properties page as seen below you need to set the value of stringvalue.

Next, add a Wait Step that we will configure to wait for the account name to change.

After adding the Wait Step, click on the condition link to be able to build the wait for condition.  Here we want to compare the account name (which will be the current value) to our saved off value in or workspace. 

To get the value from our saved workspace - use the Form Assistant Look For list to find our Create Activity.  Once you select it from the list - you should see our stringvalue property and be able to select it.

Now, for our example, let's send an e-mail to notify when the account name changes.  So to do this we add a Send Email step to our workflow

In the text of the e-mail we can reference the  old name (again referencing via our Create Activity string Value ) and the new account name (which will just be the Account.Account Name attribute)

The following is our full workflow - We Save the value by creating a workspace record, we wait for the account name change to occur by comparing the current value with our saved name and finally we send an email to notify of the change.

Next, we go create an Account and set the account name to "CRM Live" - looking at our workflow list we would see that a workflow had started and was waiting for the name change to occur.

Finally, to finish off the workflow we go modify the account name to "CRM Online".  The workflow would detect the change and an e-mail would be created as you can see below

So in this approach we have used a custom entity to save off the value of account name to allow it to be compared.  The advantage of this approach is it can be done without any custom code which means it's an approach that can be used in CRM Online (Yes CRM Live is really now CRM Online - read the announcement here ).  Couple of negative's of this approach is you have the overhead of creating a instance of the workflow space entity.  Additionally, there's no activity that can be used to remove this - so you  would have to bulk delete or otherwise get rid of these workflow state records once they are no longer needed. 

A possible alternative to this approach is to use a field on the Account entity (or whatever entity you are working with) and do an Update to the same record. The advantage there is you wouldn't need a custom entity and wouldn't have to clean up old records. 

In a future post(Part 3!), I will look at how you can build a simple custom activity that can be used to accomplish this without the need for a custom entity or extra attributes.