Thursday, February 4, 2010

Automatic Lead Assignment Using Workflows

The problem with using workflows for lead assignment is you don't know who you sent the last lead to. However, you can get around this in a couple of ways.

Method 1: Code
I'm not much of a coder so I figured I'd try to achieve it without using plugins or jscript

Method 2: The cheeky use of entities to store values
To keep track of who we last sent a lead to, we're going to create a new entity and create a record for the variable storage. Let's call the entity 'RoundRobin'. We have a few options here.
  • We could use the ownership relationship to store the next user to receive a lead
  • We could set up a new N:1 relationship to the user entity
  • We could add an attribute and store a value there

In my case I've set up an attribute.









I've also set up a 1:N relationship to Leads (they're called Enquiries here but they are just renamed Leads, I promise).

Now the tricky bit, the workflow. The steps of the workflow are:

  • Link the lead to your one RoundRobin record
  • If the attribute is 'a', assign the Lead to User1 and update the attribute to 'b' (in the case of using a relationship to the users, simply reassign it)
  • If the attribute is 'b', assign the Lead to User2 and update the attribute to 'a'

Here is one I prepared earlier:




In this case I have it as On Demand but with workflows being asynchronous, this tends to act a little weird (basically a bunch of Leads get assigned before the attribute has a chance to change). However, if you run it on the creation of the lead, it works fine assuming there is a reasonable time between lead creations.

Auto-assigning workflow-created records to the current user

One of the 'features' of Dynamics CRM is that if you use a workflow to generate records, the owners of those records will be the author of the workflow, NOT the current user. Generally this is undesirable.

So how do we get around this? Without too much difficulty actually.

The trick is we can use the event trigger to tell us who the current user is. For example, let's say we have a workflow that creates a set of task records when a new account is created. While easy to set up, all the tasks will be owned by the workflow creator and not the user. However, as we know the user created the parent account (the event trigger), we can populate the task owners with the 'created by' of the parent account.

If the status of a record changes or the attributes are modified, use the 'modified by'. If the record is assigned, check the owner.

There you have it. A really easy way to assign workflow records to the current user and not the workflow administrator.