I’ve lately been involved with quite a lot of Service Cloud implementations. One thing that I’ve noticed almost all of them have in common is that their Cases never seem to always go to the right Department – or they need to be sent to another mid-Case. The most common complaint usually has to deal with how many screens someone has to go through to successfully reassign the Case, especially if you’re in the Feed View and not the Detail View of the Service Console. If you noticed, Owner isn’t an option for us in a Record Update on the Quick Action Page Layout. So, that means we have to get creative to solve this business problem!
We need to make sure we have a few things built before we begin. In this case, we need to add two fields to our Cases.
The first field is going to be a dropdown that will allow us to mirror the list of Queues available for Cases. We will call this Assign to Queue.
The next field we need to create is a User Lookup. This we’re going to call Assign to User. We are using this in place of the Owner field, because that isn’t allowed (at the time of this post). Note: this is a Lookup to the USER Object, not CASE. The Child Relationship Name is referring to what this Lookup would be called in relationship to the User Object on a Page Layout (if that was visible), not that it is a Lookup to the User.
We could make a Validation Rule to only allow one of those fields to be filled out, but we’re just going to do a decision of ‘what matters’ in our Process Builder that will ignore that being needed.
Now that we have our Custom Fields built, lets make sure every value on the Reassign to Queue field has a match!
Now that we have that taken care of, lets build our Action! Navigate to the Buttons, Links, and Actions section under Cases and then select New Action.
For this Action we are going to be doing a Record Update. This is because we are going to be updating one of the Assign to fields we created at the beginning.
You have the option to insert your own Icon here. I like to do this for my clients and even customize it to be one of the colors from their logo. I’ve got a post coming shortly on how you would do this, but for the meantime you can go checkout http://www.lightningdesignsystem.com by yourself!
Now we need to clear out default layout our Action has.
To finish our Action we just need to drag in our Queue and User fields. Once you do this hit Save and you’re done with your Action!
Now we need to go add it to our Case’s Page Layout. We want to drag it down to the Quick Actions section. If you haven’t customized your Salesforce1 Actions yet, they’ll just mirrors your Quick Actions layout.
And this is what it looks like!
Now, lets jump over and build out our Flow! (Setup | Create | Workflows & Approvals | Flows)
The first step is going to be grabbing our Record Lookup.
We’re going to be needing to create a variable to store our Queue Name, which we will pass in from our Process Builder.
Notice, we are using a filter to make sure that Type = Queue. This is because the Group Object houses more than just Queues. It houses other types of Groups like Public Groups! We just want to make sure we bring back the correct ID in case another type of Group has the same Name.
Now lets create a variable to store that ID that we are looking to get.
Our finished Record Lookup will look like this:
Lets set it as our starting element
The next thing we are going to do is to use a Decision to validate that we found an Id. You can read more about it in my post on using Decisions as your Test Coverage, so we won’t cover this step in detail here.
Now, lets drag in a Record Update element so that we can update our Case!
We want to create a variable to house our Case Id that we are going to pass in from our Process Builder. This allows us to make sure we are updating the correct Case.
We need to update the OwnerId with our variable var_QueueId, and to update the Assign to Queue field with an empty string so that it can be used again.
After saving our Record Update, we need to connect our elements together and then save our Flow.
Make sure you activate your Flow or it can’t be referenced in Process Builder!
Now, our Flow is completed and activated, but right now its doing nothing! So we need to have a Process Builder trigger it. However, did you notice it seems like we’re missing something? We also have the Assign to User field. We didn’t put that in our Flow! Well, turns out we don’t need to. We can take care of that in our Process Builder!
So lets go create a new Process Builder for this. (Setup | Create | Workflows & Approvals | Process Builder)
Set this to have the ability to fire from the Case Object on when a record is created or edited.
For our Criteria we need it to be whenever our Assign to User is filled out, which would be the equivalent of saying that it isn’t null. So, lets use “is null” equals “false” as our conditions.
When this happens, we want to do a Record Update to change the OwnerId to the Assign to User Id, as well as we want to clear out any values in the Assign to User and Assign to Queue fields.
Now that we’ve got our first situation complete (when the Assign to User is chosen), lets work on our second one (when Assign to Queue was chosen).
When we meet this criteria, we want to go to our Flow and do our query to see if we find a matching Queue. So lets create our Flow Action and pass in our variables.
Hit Save and then Activate your Process Builder and you’re done! Go grab a nice drink and enjoy your accomplishment!
Hopefully the combination of Actions, Flow, and Process Builder has got your mind racing with cool automations you can make yourself!
Salesforce Sidekick 
Thanks for the write-up! I am having one small issue though. When I try an Assign to Chosen User I can’t select [Case].Assign_to_User__c field. I believe that because it is a lookup it is requiring me to select a field from the User object. Any idea why?
LikeLike
Allen, are you using a User Lookup as your Assign to Chose User field? That way you’re pulling from a list of Users. If you’re not, you’ll have to query Users within a Flow and then map the queried ID to the OwnerId. But ideally you can do it within PB by using a User Lookup field for that Assign to User field.
LikeLike
This is great David, thank you very much for the elaborated article.
One small feedback though – I also couldn’t get the ‘assign to user’ right, as originally created the ‘assign to user’ lookup field in relation to Case (and not User).
It might worth adding this small piece, as in my case I had to re-run the procedure with the correct ‘assign to user’ field.
LikeLiked by 1 person
So glad you liked it. I will most definitely update that to be more clear. I see how the image is not very specific in referring that it is a User Upload (since the child relationship makes it look like you’re doing a Lookup to Cases and not User). Thank you for the great constructive feedback!
LikeLiked by 1 person
Quick question – how does the newly exposed ‘owner id’ field in the upcoming winter 17′ release affects this solution?
I’ve tried adding the ‘owner id’ in the customized ‘close case’ action in my updated sandbox instance, but it appears to be greyed out, and not available to be added.
Thank you,
Ido.
LikeLike
Ido,
The Owner ID field in the Winter ’17 release is different from what you’re referring to. The Owner field is already available (was released in the Summer release I believe), and that field functions just as a regular Lookup does. You could potentially replace the Owner field with the Lookup field, and it will be defaulting to the current owner. So, while you technically don’t have to use this workaround anymore to reassign the Case, it can be beneficial to have the dropdown for Queues and a blank Lookup for the User reassignment instead of having to clear it yourself.
I know many End Users prefer the dropdown option for a Queue, which I think is one main reason this particular set of automation stays applicable after the addition of the Owner field.
LikeLike
Thanks for the reply.
Fully understood. We also benefit from the ability to change owner by Queue, as our escalation relies on teams, rather then specific individuals.
Thanks again for putting this up, it has been very useful.
LikeLike
Hello David,
I’m getting the following error when trying to assign to a queue:
Error Occurred: UPDATE — UPDATE FAILED — ERRORS : (FIELD_INTEGRITY_EXCEPTION) Owner ID: id value of incorrect type: 5001b000001KLTCAA4
RECORD UPDATE: Update_Case_Owner
Find all Case records where:
Id Equals {!var_CaseId} (5001b000001KLTCAA4)
Update the records’ field values.
Assign_to_Queue__c =
OwnerId = {!var_CaseId} (5001b000001KLTCAA4)
Result
Failed to update records that meet the filter criteria.
Can you help?
Thanks Igor
LikeLike
Hi Igor,
Based on your Error message, you’re trying to insert the Case ID as the Owner ID. Notice, the Owner ID value starts with 500. That is your Case ID not the correct Queue. It seems that you’re Record Lookup to the Queue might be where your issue is. I would validate that you’re querying and finding the right Queue ID and that the ID is being passed into the OwnerId field. Let me know if that fixes it!
Thanks,
David
LikeLike
Hi David,
How Can we achieve this if, Assign_to_User__c is picklist?
Thanks,
John
LikeLike
Assign_to_User__c should be a regular User Lookup. If not, and it is a picklist as well, you can mimic the same process we have for Assign to Queue, but search for the User ID instead of the Group ID. You’ll do a search on the User with a filter on Name = Assign_to_User__c … note, you might need a Full Name custom field on the User to have a match.
LikeLike
Thank you David! That fixed the issue and the its all good now.
LikeLike
Hey David,
I fill a little stupid for asking, but I want to add an additional Queue to be available in the ‘Assign to Queue’ dropdown list.
I added the new Queue in the ‘Assign_to_Queue’ custom field, but I can’t understand why it’s not available in the pick list.
I double checked the Flow and Process Builder’s Process and there doesn’t seem to be any hardcoded evidence for the values of the ‘Assign_to_Queue’ picklist.
Is there anything I am missing?
Thank you,
Ido.
LikeLike
Ido, That is interesting behavior. You’re saying that you added it to the picklist. but you don’t see it? I assume you’re doing this in an Action where the Record Type values of the picklist don’t matter and it shows all values. Is that correct?
LikeLike
Thanks for the reply David.
Yes, I simply added an additional value to the ‘Assign to Queue’ Case Custom Field – called ‘security’. Obviously the ‘Security’ was added as a ‘queue’ in Setup (under ‘Queues’).
A screenshot with the current Custom Field setting is here – http://www.screencast.com/t/Zi3Kwk4ja
The ‘Security’ queue is not available in the ‘Assign to Queue’ picklist under the relevant Case Feed action. Screenshot here – http://www.screencast.com/t/obNqc7g5GHpo
Do you have any idea why this can happen?
Thank you,
Ido.
LikeLike
Ido,
The reason is that you’ve got Record Types in there. You need to add that value to your Record Type’s allowed values. Once you do that, it should be visible.
It seems that Salesforce has now made that something enforceable (I recall a while back it wasn’t dependent on the Record Type for an action’s field values)
Fix – navigate to the record type(s), go to the picklist field, and add in the new value to all record types you want it visible on. In the future, check the boxes when you add the values and you can do it when you add the value.
LikeLike
Thanks David.
Much appreciated.
LikeLike
This is fantastic! I tested in Sandbox and works like a bomb.
LikeLike
Hi, can this be done in Sales Cloud as well?
LikeLike
Yes, this concept works for Sales Cloud (specifically Leads since it can have Queues). But really can be repurposed for any object.
LikeLike