Reassign Case using a Quick Action and Flow

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.

Reassign 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.

User Lookup

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!

Queues.jpg

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.

New Action boxFor 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.

Action Update a Record

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!

Action Change Icon

Now we need to clear out default layout our Action has.

 

Clear Layout

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!

Edit Action Layout

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.

Drag into Layout

 

And this is what it looks like!

Finished Action

 

Now, lets jump over and build out our Flow!  (Setup | Create | Workflows & Approvals | Flows)

New Flow

The first step is going to be grabbing our Record Lookup.

RecordLookup1

We’re going to be needing to create a variable to store our Queue Name, which we will pass in from our Process Builder.

var_QueueName

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.

Find Queue

Now lets create a variable to store that ID that we are looking to get.

var_QueueId

Our finished Record Lookup will look like this:

Find Queue 2

Lets set it as our starting element

SetStartElement.jpg

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.

Add Decision.jpg

QueueDecision.jpg

Now, lets drag in a Record Update element so that we can update our Case!

Drag Record Update

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.

var_CaseId

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.

UpdateCase

After saving our Record Update, we need to connect our elements together and then save our Flow.

FinishedFlowQueue.jpg

Save Queue Flow.jpg

Make sure you activate your Flow or it can’t be referenced in Process Builder!

ActiveFlowQueue.jpg

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)

NewProcessBuilderQueue

Set this to have the ability to fire from the Case Object on when a record is created or edited.

onCaseObject

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.

Criteria #1.jpg

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.

Record Update in Process Builder.jpg

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).

Criteria #2.jpg

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.

SetFlowVariables.jpg

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!

How to setup a recurring scheduled Process Builder and/or Flow

***UPDATE***

My recommendation is to use this solution by Doug instead of following the steps below: https://douglascayers.com/2016/04/18/salesforce-process-builder-scheduler/


 

In Apex you’re able to setup a recurring job that will fire whenever you’d like.  However, now that many of the solutions that we previously needed Apex for can be solved through Process Builder and Flow, it would be great if we could setup a schedule to do batch jobs without Apex.  I’ve recently come across more and more clients wanting something to run from every 15 minutes to every business day.  Unfortunately, I’m not savvy enough with Apex (yet!) to feel comfortable writing a trigger just to get this added functionality.  So, that is when I got creative.  With just three workflow rules we are able to setup our own scheduled Flow!  (So that means, we’re not actually going to be building a Flow in this post, sorry!) Continue reading

How to use a Fast Create

The first time I saw Fast Create I was quite confused.  Is a Record Create slow?  Well, it is actually slower if you want to create multiple records at once.  A Fast Create really is more than just one element.  This is because you must build records to put in a SObject Collection Variable that you will then insert with your Fast Create.  If you’re new to this element, you’re probably wondering what the heck I am talking about.  Lets go over our use-case and then we will make sense of this madness.

Continue reading