First-Come First-Served Lead Assignment Workflow Using CRM Queues

Assigning Records Using Queues? Everybody knows you can’t do that!

We can refer to this as assigning on a “first-come first-served” basis, since whoever accepts the record first gets it. Using an approach I will outline here, we can use queues to assign Lead records in this way…even though Lead records themselves — along with every other record in CRM other than Activity and Case records — cannot be assigned to a queue!

Setting Up and Building the Workflow

I wrote this workflow using the downloadable public CRM 4.0 VPC image. To build it by following the steps provided, you need to do a little setup first:

1. Create a business unit called “Sales” under the root business unit, adding Amy Alberts to that business unit and assigning her the security role of Sales Manager.
2. Add a few more users to the Sales business unit you can use for testing, assigning them to the Salesperson security role.
3. In order to get this to work right you’ll need to slightly modify the Salesperson security role, but I’ll tell you how to do that at the end of the article.   

We will use an automatic workflow that runs when a new Lead record is created. It will create a Task record and assign it to a queue. A user will be able to see the new Task record in the queue, and will be instructed to accept and complete the task in order to “claim” the new Lead. The workflow will wait until the task is completed, and then assign the Lead record to whichever user completed the task. This is actually a general technique and can be used to assign ANY record in Dynamics CRM, but we will use the Lead entity to illustrate. Here’s how to do it:

Start by creating a queue appropriate for this process. Navigate to the Business Management tab in Settings, click Queues, and click New from the Queues grid. We will call our new queue “Open Leads”, and assign it to the root business unit.

Once the queue is created, follow these steps to create the workflow:

1. Create a new workflow on the Lead entity with an appropriate name, scope it at the Organization level, and have it run automatically on the “Record is created” trigger. You can see these in the Workflow Properties section here:

2. The first action in the workflow will be Create Task. Click Set Properties on the Create: Task line to open the Create Task dialog, which you can see in the next figure.  The Regarding field will already be filled in with the Lead. We used Dynamic Values to pop the Lead Topic onto the end of the Subject line, but that’s optional.

Notice that this workflow makes “Amy Alberts” the Owner of the task. In the CRM organization this was created for, she is assigned to the Sales business unit, and has a security role of Sales Manager. We could leave the Owner field empty here, but that would cause other problems we will discuss below. The reason the Owner field is not required in automatic workflows like this one is that the workflow runs in the security context of the workflow’s owner. Since this workflow is owned by the system administrator, any record it creates that does not have a different user specified as the owner will be owned by the administrator.

3. After the Task record is created, the next action in the workflow is to “assign” that Task record to the Open Leads queue. Remember, assigning to a queue doesn’t change the owner of the task. (I always put “assign” in quotation marks to remind myself so I don’t forget!) On this step you don’t need to use Dynamic Properties since you can simply enter the name of the queue onto the lookup field you can see back in the screenshot in step 1.
 

4. After putting the Task record into the queue, add a Wait condition. The workflow will wait until the Owner of the Task record changes – which will happen when any user other than Amy the Sales Manager accepts the Task record from the queue. The next figure shows how you can specify that Wait Condition. Notice you need to identify the Task in the “Local Values” section of the drop-down menu. Any record that a workflow creates will be available in Local Values, and once you select it you can access its attributes – in this example, to specify the condition the workflow will wait for.
 

5. After specifying this condition, save, close and publish the workflow to see how it works.

Queues, Record Assignment, Security Roles and Workflows

This workflow raises some interesting issues regarding queues, record assignment, security roles, and how they interact with workflows. Basically, any user who will accept one of these tasks to get the lead assigned to them must have sufficient Assign privilege on the Activity entity. The standard Salesperson security role only has User-level Assign privilege on Activity (along with most of the other core records, including Lead). What this means is that by default, a user assigned to the Salesperson security role will not be able to accept activity records from a queue (such as the Task record we used in this example).
Suppose that we had not specified the Sales Manager as the owner of the task record created in the workflow as we discussed above. In that case the task would be owned by the system administrator, who is assigned to the root business unit. If a user assigned to the Sales business unit with a Salesperson security role attempts to accept the task from the queue, he or she would see this rather dramatic error message:

This is why we assigned the new Lead records to the Sales Manager, who is in the same business unit as the Salesperson(s). We then needed to make one change to the Salesperson security role: elevate the Assign privilege on Activity from User to Business Unit. We highlight this in the next figure.

After making this change, a Salesperson in the same business unit as the user to whom the activity has been assigned (Sales Manager Amy, in our example) can accept the task record from the queue successfully. You might think they also need Business Unit level Assign for Lead, but they don’t. This is because it’s the workflow that does the assigning of the Lead record, and the workflow runs in the security context of the owner of the workflow! Since the user has to manually accept the Task record from the queue that happens in their security context and they need these slightly higher privileges on the Activity entity.