How to let a non-Admin EASILY assign Permission Sets and/or Public Groups

Once and a while you get into the situation where you want a non-Admin User to manage a few specific Permission Sets and/or Public Groups.  Let me start this off by saying Delegated Administration is a fantastic option to use.  However, I’ve run into the scenario where that sometimes doesn’t do the trick.  If you’re dealing with someone non-technical this type of Admin work can be a difficult End User experience.  One of the most often times I do this is working with special permissions for Community Users.  That is because Community Users don’t even have Public Groups visible on their User Detail!  So, if the manager has administer more than type of group or assignment, it is easy for them to make a mistake.  So, how can we make this as easy of an experience as possible and help to reduce errors?

Simple, we use a Checkbox (and sometimes a Picklist)!

checklist

In this post we are going to go over my method of simplifying how you can assign Permissions by using a field on the User Object that any User can be given access to.  Let me reiterate why I do this:

  1. Makes it dummy proof.  It takes the thought out of the End User managing the Permission.  All your End User needs to do is Check or Uncheck a box (or select a different picklist value).  There is less of a chance for them to add or remove the wrong permission.
  2. A List View cam show your End User who has (or hasn’t) been given the permissions they’re assigning.  This makes it easy for them to see whose been given the appropriate access, and they don’t have to go into the Permission Set, Public Group, Queue, or Chatter Group to verify they’ve removed or added someone.
  3. Easier training for the Admin.  It isn’t as hard to train someone to check a box or use a picklist!

Ok, so now that we have established why I think this is a great solution, lets get rolling!

For this example we are going to go use a Checkbox to assign a Permission Set to a Community User.  The Permission Set will be granting access to our Knowledge Article Type that is only available for our Premier Support customers (similar to Salesforce’s Premier Support).  To do this, we need to create a Checkbox on the User Object, and make sure we only give access to the appropriate Users (assign via Profile or Permission Set).

Note: while we are only assigning a Permission Set in this example (to keep it simple), you can easily add on using this same blue print and swapping out the Object to whatever Object you need.

Automation Overview:

  1. User Record Meets Criteria – Process Builder triggered (Pass inputs into Visual Flow)
  2. Flow Checks to see if existing Permission Set Assignment
  3. Flow Determines if we add or remove the Permission Set Assignment
  4. Flow adds or removes the Permission Set Assignment

We will be creating:

  1. Premier Support [User Field – Checkbox]
  2. Flow to run our logic
  3. Process Builder to launch our Flow

So start off by creating your new Checkbox field

Premier Support.jpg

Now that we have our Premier Support Checkbox created, we can go create our Flow (Setup | Create | Workflows & Approvals | Flows).

NewFlow.jpg

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

Record Lookup1.jpg

We are going to be doing a Lookup on our Permission Set Assignment Object.  We want to see if we have a matching Permission Set Assignment or not.  We will want to setup our criteria, and set an ID if we find a Record.  To do so we will need to have these three variables created:

var_UserId – The Id of the User the Process Builder is triggered from (passed in from PB)

var_UserId.jpg

var_PermissionSetAssignmentId – The Id of the Permission Set Assignment, if the User has been assigned the Permission Set already.

var_PermissionSetAssignmentId.jpg

var_PermissionSetId – The Id of the Permission Set associated to Premier Support (passed in from PB)
var_PermissionSetId.jpg

This will give us a final Record Lookup that looks like this

Finished Record Lookup

Great, now lets set this as our Start Element

Set Start Element

Now, we need to setup a Decision to see if we need to add or remove the Permission Set assignment.  So, lets drag that out to our Canvas.

DragDecisionOut.jpg

We will need to have a variable for our Checkbox field.  So lets create that and call it var_PremierSupport.  Make sure you set it to the Type of Boolean.

var_PremierSupport.jpg

Now, lets setup our Decision Criteria.  The first one will be if we want to ADD the Permission Set to the User, we want to check to make sure the var_PremierSupport EQUALS TRUE and the var_PermissionSetAssignmentId IS NULL is TRUE

Add

The second one will be if we want to REMOVE the Permission Set from the User, we want to check to make sure the var_PremierSupport EQUALS FALSE and the var_PermissionSetAssignmentId IS NULL is FALSE

Remove

If for some reason we don’t meet either of those criteria, we are going to leave it be and let it exit the Flow (because something is wrong).

Note: You probably want to setup some sort of Fault email to be sent to yourself so that you know there was an issue (possibly an Admin assigning the Permission Set already), but hopefully that won’t ever happen.

Now, lets drag out our Record Delete.  This will be for when our record matches our Remove criteria.

Record Delete.jpg

This is an easy Element to setup.  We just have to select the Permission Set Assignment Object and then map our Id to the Id field.

DeletePermissionSetAssignment.jpg

After we save this Element, make sure you map your Decision to it with the Remove outcome.

Now, let us drag out a Record Create.  This will be for when our record matches the Add criteria.

DragRecordCreate.jpg

Great, now we just need to select our Permission Set Assignment Object and then map our var_UserId and var_PermissionSetId fields.

RecordCreate

Now, we need to map our Decision to the Record Create.

FinalFlow.jpg

Lastly we want to Save and then Activate our Flow!

SaveFlow

Note: I like to append “- Flow” to my Autolaunched Flows.  This makes things clearer when I am dealing with them on the backend since Flow and Process Builder both are in the Flow metadata folder.

ActivatedFlow.jpg

Fantastic!  Now we need to setup our Process Builder that launches this Flow.  So lets go create a new Process Builder for this.  (Setup | Create | Workflows & Approvals | Process Builder)

CreatePB

We want the Process Builder to fire on our Account, so for our object select User, and for starting the process select when a record is created or edited.

SetUserObject.jpg

Now we need to setup our Criteria.  Unfortunately an ISCHANGED function doesn’t run on new Cases.  So we have to break out the formula editor and use this formula:

(ISNEW() &&[User].Premier_Support__c = TRUE)  || (ISCHANGED([User].Premier_Support__c))

 

ActionCriteriaPB.jpg

Now we get to setup our Immediate Action of launching a Flow.  All we need to do is pass in our User Id(Reference), Premier Support (Reference), and Permission Set ID (String).

Note: we are to breaking my hard coding an Id rule for this example.  I would recommend that you pass in the Permission Set Name and query for the Permission Set ID in your Flow.  I am ignoring that because I want to keep this blog post simple.

Launch Flow

Hit Save, and then hit Activate up in the top right corner… and you’re done!

How to bypass User Permissions with Flow

Have you ever come across a permission limitation that you couldn’t solve using a Permission Set?  Every once and a while we get requirements that can test the limits of what we can technically do with Salesforce.  It might be a Field Level Security issue, or it might be a License limitation.  Before Process Builder was around, if you wanted to get by some sort of limitation like this, you had to write code.  Not anymore!  Process Builder runs in the context of the System.

So… when Visual Flow is that when its autolaunched by Process Builder, it too will run in the context of the System and not the Running User.  This means any Field Level Security, Profiles, Roles, or License type can essentially be ignored.  Think of an Autolaunched Flow as temporarily giving somebody temporary Admin access.  Where this can get interesting is when we start to think of all of the different ways we might use this!

ProcessBuilderIcon

Get creative!  You can do all sorts of cool things to bypass Licenses and Security  issues by using Autolaunched Flows.  Here are a two examples to get you thinking:

Site.com Guest User Access

In this scenario we want to send an email to our clients to propose that we close a Case, and in that email present them with a Yes and No button.  If they click the button you want the Case to properly react.  That means we need to have that button click send them to a specific URL (associated to our Site.com) with a unique parameter that matches to our Case.  The problem is we are unable to have an unauthenticated User edit a Case.  We can give the Site.com Guest User access to Create on a Custom Object, and have that Custom Object then trigger a Process Builder to run and find and edit the Case.  There are some obvious security issues, but they can be solved by building your parameter and Flow correctly.

Add and Remove Permission Sets and Public Groups

We want our Marketing Manager to be able to add and remove people to a Permission Set and/or Public Group.  We can create a Checkbox or Picklist on the User Object, and have an edit to that field trigger a Process Builder to launch our Flow where we either add or remove them to the Permission Set and/or Public Group.  Access to this field can be then controlled by a Permission Set or by Profile.  With this, we can essentially delegate any Admin function to any User without given them Admin privileges!

How to track the Case Age of each Status

I’ve been running into many scenarios where people want to track the Age of each status (be it Case or another Custom Object).  We’ve got things like Field Tracking that we can use to get close, but the data isn’t very easy to build dashboards and reports on.  So, my mind immediately went back to one of my first posts and Flows, Case Time Tracking.  In this post we were wanting to see how long the Users had worked on a Case, and not how long our Cases were staying in a status.  But architecturally we’re going to be pretty similar.

Automation Overview:

  1. Case Meets Criteria – Process Builder triggered (Pass inputs into Visual Flow)
  2. Flow Checks to see if existing open Record
  3. Flow Updates existing record if possible
  4. Flow Checks to see if Case is still Open, exists if Closed
  5. If Case is Open, Flow creates new Record

We will be creating a few fields on our Custom Object:

  1. Case [Master-Detail Lookup]
  2. Start Time[Date/Time]
  3. End Time [Date/Time]
  4. Status [Picklist – Mirror Case’s values]
  5. Minutes [Formula, Number, 2 decimals]

For our Minutes Formula we want to use this:

IF ( ISBLANK ( End_Time__c) , 0 , ( End_Time__c – Start_Time__c ) * 1440 )

Depending on your business case, you might want to change this to be Hours or Days instead of Minutes.  Also, you might want to make 

Here is what our finalized Object looks like:

Case Age 2

Now that we have our Object ready, we can go create our Flow (Setup | Create | Workflows & Approvals | Flows).

NewFlow.jpg

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

RecordLookup.jpg

We are going to be doing a Lookup on our Custom Object we just created to track the Status Ages.  We want to first check to see if one is already open on this Case, and if we need to stamp the open record with an End Time.  If not, then we can ignore going to a Record Update and go to a Record Create if the Case Status is not closed.  For our Record Lookup, we need a variable for our Case’s Id and our Existing Status Age Id (our new Custom Object).

var_CaseId.jpg

StatusAgeId

Which gives us our Record Lookup.  If you notice, we are using IS NULL with the Start and End Date fields.  We simply want to find a record that has a Start Date but doesn’t have an End Date.  That would equate to being an open record that we need to update with an End Dat

Record Lookup for Case Status Age.jpg

Set the Record Lookup as our Start Element

startElement.jpg

Now, we want to drag a Decision Element into our canvas to determine if we found a Record in our Lookup or not.

Add Decision to Flow.jpg

Call the Decision Element “Existing Record?”.  For our first Decision Criteria or Outcome to be checking to see if our variable of the Case Status Age is null or not.

Decision in Flow.jpg

Now, we want to drag in a Record Update element to update the existing Case Status Age record, if we found one.

DragOutRecordUpdate.jpg

We will want to use for our criteria the Id of the record we found in our Lookup.  For the fields we will update, we want to use the System variable, CurrentDateTime

RecordUpdateCaseStatusAge.jpg

Update End Date.jpg

Now, lets drag out another Decision Element.  We need to determine if our Case is Closed or not.  If it is Closed, we don’t need to create another record.  If it is Open, then we will create another Case Status Age record.  So, lets call the Decision Element “Case Closed?”.

AnotherDecision.jpg

We want to create a variable called var_CaseIsClosed that will be passed in from the Process Builder.  Note: this is a BOOLEAN field.  We will check to see if var_CaseIsClosed is FALSE.  If so, we will proceed to our Record Create, but if it is TRUE we will let it exit the Flow.

CaseIsClosedBoolean.jpg

CaseIsClosedDecision

Hit OK, and we now get to map our elements together.  Notice, we map our Record Update to our second Decision Element.

MapDecision.jpg

Now we need to drag out a Record Create.

DragOutRecordCreate.jpg

We need to create a variable called var_Status, which just like var_CaseIsClosed, will be passed in through our Process Builder.

var_Status.jpg

We now will setup our other inputs on the Record Create to be our Case’s Id and the Start Date (which we will use the System Variable again).  This is our last element of the Flow, so we don’t need to assign the Record ID to a variable.

CreateCaseStatusAge.jpg

Now, we need to map our Decision to the Record Create.

FinalizedCaseStatusAgeFlow.jpg

Lastly we want to Save and then Activate our Flow!

SavedFlow.jpg

Note: I like to append “- Flow” to my Autolaunched Flows.  This makes things clearer when I am dealing with them on the backend since Flow and Process Builder both are in the Flow metadata folder.

ActivatedFlow.jpg

Fantastic!  Now we need to setup our Process Builder that launches this Flow.  So lets go create a new Process Builder for this.  (Setup | Create | Workflows & Approvals | Process Builder)

NewPBCaseStatus.jpg

We want the Process Builder to fire on our Account, so for our object select Case, and for starting the process select when a record is created or edited.

CaseStatusPB.jpg

Now we need to setup our Criteria.  Unfortunately an ISCHANGED function doesn’t run on new Cases.  So we have to break out the formula editor and use this formula:

ISNEW() || ISCHANGED([Case].Status)

CaseStatusChanged

Now we get to setup our Immediate Action of launching a Flow.  All we need to do is pass in our Case Id, Case Status, and our IsClosed field.  Note: the IsClosed is listed as Closed in Process Builder.  IsClosed is the API Name for that field.

Set Case Status

Hit Save, and then hit Activate up in the top right corner… and you’re done!

How to Create a Conditional Auto Number

Every once and a while there is a situation where we need to have an Auto Number generated, but only for records that meet a certain criteria.  Lets say that we use the Account Number field as our client’s identifier, and we want to automate this process of incrementing it one every time we have a new client.  There are a few different ways that we can solve this, but we’re going to use Visual Flow.

Automation Overview:

  1. Account Meets Criteria – Process Builder triggered (Pass inputs into Visual Flow)
  2. Custom Object Record with Auto Number created in Flow
  3. Lookup value of Auto Number
  4. Update the Account

For this solution we have three different options in how we can do it architecturally (with our Auto Number):

  1. Custom Object
  2. Custom Metadata
  3. Custom Settings

For me, I am going to go with using a Custom Object.  I think that it is the easiest option of the three to implement, and most Salesforce Admins can relate to Custom Objects more than the other two options.  So, what fields do we need create in this Custom Object?  None!  We just need to make sure we set the Name to be an Auto Number.

AutoNumberObject.jpg

HINT: If you ever need to reset the number, you can switch the Name field to Text and then back to an Auto Number and it will let you pick the Starting Number again.

Here is what our finalized Object looks like:

AutoNumberCustomObject.jpg

Now that we have our Object ready, we can go create our Flow (Setup | Create | Workflows & Approvals | Flows).

NewFlow.jpg

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

RecordCreate1.jpg

We want to select the Client Number Object that we just created, and then remove the row asking us to set a field value.

RemoveField.jpg

Now, we want to create a variable to house the Record Id.

var_ClientNumberId.jpg

CreateClientNumber

Hit OK, and then we want to set this as our Starting Element.

StartingElementCreateClientNumber.jpg

Now, we want to grab a Record Lookup and find the Name (Auto Number) of the record we just created.

AddRecordLookup.jpg

We are going to need to create a variable to store the Auto Number value that we will then Update our Account with.

var_ClientNumber.jpg

FindAutoNumber

Hit OK.  And now drag out the Record Update element.

RecordUpdateClientNumber.jpg

We will be passing into our Flow the Account Id value, and we will want to use that here to filter on our Record Update.  So we need to create the variable to store that.

var_AccountId.jpg

Map the Client Number to the Account Number field, and hit OK.

UpdateAccountAccountNumber.jpg

Connect the elements together to finish our Flow.

CompletedClientNumberFlow.jpg

And lastly we want to Save and then Activate our Flow!

CreateClientNumberFlowSave

ActivateClientNumberFLow.jpg

Fantastic!  Now we need to setup our Process Builder that fires this Flow.  So lets go create a new Process Builder for this.  (Setup | Create | Workflows & Approvals | Process Builder)

CreateClientNumberPB.jpg

We want the Process Builder to fire on our Account, so for our object select Account, and for starting the process select when a record is created or edited.

PB1.jpg

This next step is completely on you for when the record meets the criteria.  For my example we will just use when the Type is now a Customer.  Careful with the Advanced section at the bottom, you aren’t going to want your Process Builder to fire more than once per Account!

NewCustomerCriteria.jpg

Now we get to setup our Immediate Action of launching a Flow.  All we need to do is pass in our Account Id.

PBLaunchFlow.jpg

Hit Save, and then hit Activate up in the top right corner… and you’re done!

 

 

 

Close Cases with a Quick Action

If you have used Cases in Salesforce, I am sure you’re aware of the Closed Case layout.  This is great, it lets you require the fields that must be filled out before a User can close a Case.  Now, the issue comes when Salesforce rolled out the Feed View in the Console.  Our Users are supposed to live in the Feed, and it would be great if we could have a Quick Action for closing the Case so it is easy to use on the Desktop and Phone!  However, if you’re limiting Close Statuses to the Close Case Layout, you can’t simply drag in your Status field!  You’ve got to get creative!  So we’ll show you how with a Quick Action and a Process Builder we can make our own customized Close Case Quick Action!

How do we do this?

  1. Create our new Fields
  2. Create the Quick Action
  3. Create the Process Builder
  4. Add the Quick Action to the Page Layout

Lets get started!  First, lets create Close Status, which will mirror what your existing closed Status values are.  Remember, if you add a new closed Status value, you’ll need to update it here too.  Not ideal, but it is all we can do right now.

Close Status.jpg

Next, we want to add in a field that will let us know our Quick Action has been fired.  This will be a Checkbox field.

CloseCaseQuickAction.jpg

Now that we have all of our new fields, lets go and create a Quick Action.  To do this, we want to navigate to the Buttons, Links, and Actions section under Cases.  From there, we will hit New Action.

New Action.jpg

We want to now select our Action Type to be Update a Record, which means we are updating the record the action is executed on.

UpdateRecord

Now lets name our Action Close Case and then we get to do my favorite two parts of an Action!  We get to create our Success Message and add our custom Icon.  For those of you new to seeing the Success Message, this will be displayed after someones hits Update on our Action and close the Case.  Previously we weren’t able to modify that message, but now Salesforce gave us that power!  So lets use it!

Success Message

For this Action I’ve got a trophy from the Lightning Design System I want to use.  If you’re unfamiliar with the Lightning Design System and how you can use it to make your Actions and anything Lightning look awesome, check out my post on it!

First, lets get rid of all the fields on the default Layout.

ActionLayout1

Now, lets add in the fields that we want for our Closed Case Layout, and lets set the fields required that we want to require them to use.

ActionLayout2

As you go to save the Action you’ll see a warning message from Salesforce letting you know a required field (Status) is not on your layout.  You can ignore it 🙂

ActionLayout3

Before we move on, we need to use the Predefined Field Values to our advantage, and have Close Case QuickAction set to TRUE.  This will allow us to know every time the Action is pressed, and when we want to trigger our Process Builder.

Predefined FieldsPredefined TRUEPredefined DoNE.jpg

Now on to creating our Process Builder!  This is where the magic comes in.  If you noticed, our field Close Status is not magically linked to the Status field.  But, we need it to be.  The reason we are using Process Builder and not a Workflow Rule is Workflow Rules are not able to pass in a dynamic value of a field, but Process Builder can!  With Process Builder we will be able to make any update to the Close Status field pass into our Status Field.

Lets go create a new Process Builder for this.  (Setup | Create | Workflows & Approvals | Process Builder)

New PB 1.jpg

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

PB2.jpg

For our Criteria we need it to be whenever our Close Case QuickAction boolean is TRUE.  We also want to check in our Advanced section the box to make sure we don’t keep firing this Process Builder with every edit (though, our Record Update technically would stop that).

PB 2.jpg

When this happens, we want to do a Record Update to change the Status to the Close Status value, and we want to reset the Close Status QuickAction field to FALSE.

PB 3

Now Save & Activate the Process Builder.

To finish up, lets navigate over to the Page Layout editor and drop in our new Quick Action!

Page Layout 1.jpg

Hit Save.  Now lets navigate to a Case and check out our hard work in action!

Page Layout 2.jpg

Fill out the required fields, hit Update, and watch the Case get closed!

Page Layout 3

Hopefully the simple combination of  an Action and Process Builder shows you how easy it is to take your Actions to the next level!

The 6 Most Common Visual Flow Errors to Avoid

Visual Flow and Process Builder have gained adoption around the Salesforce Community.   We are even allowed to Activate a Flow or Process Builder in Production without ever testing it is actually working as we intended.  This means that when we develop a Process Builder or Flow we are quite likely to run into errors.  These errors are the main mistakes that you should look out for when you are building a Flow.  I’ve hit all of these errors, and I still continue run up against some of them.  However, knowing what to lookout for will save you a headache when you do run into one!

No Access to Running Flows

This is an easy fix and you’ll only run into once (per Org that you work in).  Make sure any users that need to access a Visual Flow have the System Permission Run Flows.  If the End User lacks this permission and they attempt to access the Visual Flow they’ll receive an error.

Object & Field Level Security for running user

If you are using Visual Flow (not launched by Process Builder), this is an error you can run into.  This can cause all kinds of issues when your Lookups, Creates, and Updates all break.  This is something that you can’t really fix within your Flow, and this is strictly user permissions.  This comes down to you as the Administrator knowing the level of security your users that will be using your Flow.  So, make sure your End Users have the ability to do everything you want them to or they’ll get an error!

Too many SOQL queries

Fortunately this is a limit that usually only Admins run into.  It is rare our End Users actually preform data loads, or use an Autolaunched Flow hits this limit.  Unfortunately we don’t actually have a limit status bar as an option, and it doesn’t seem like this is coming anytime soon.

Now, when you’re building a complex Flow, you need to consider how it is going to be used.  Are you likely to hit limits on?  Are there other Workflow Rules, Process Builders, Auto-launched Flows, or Apex Triggers that will be touched by your automation and might cause a ‘loop’ of your automation?

The best advice I can offer for you with this error is to assume you will always hit it with data loads.  But, in the case when you don’t… TEST, TEST, and TEST again.  There is no magic status bar to alert you how you are tracking.

Flow SOQL.jpg

Using the wrong Field or Variable

This one is really just a User error issue.  This typically happens to me when I am working late at night.  Sometimes I might confuse the variable that I am looking for.  Often times I find this might happen when I see people creating or doing lookups to Junction Objects.  This is because we often do not use the name of the Object as our field name.  For instance, if we are tracking Job postings in Salesforce and on our Application we have the Contact lookup labeled as Applicant.  If I wasn’t paying attention, I could easily grab the wrong field to reference as my Contact Id… this plays into our next common error.

PittyFoolAwkwardLookup

Creates with no variable as your criteria, or Updates with No Records Found

So we are excited to throw our Flow out into Production, however we didn’t realize that there might be a scenario that our Flow might get activated and one of our variables isn’t populated.  This could be for a number of reasons, but it will cause you a big problem.  This will get you one of our favorite FlowApplication error emails.

Now, the way we can attempt to solve this error is to use Decisions to validate that we actually found the variables that we expected to find.  Take a moment and read my Decisions – Your Flow’s Test Coverage.  By using this method you can hopefully avoid running into these two errors altogether!

Duplicate Value – Membership/Assignment already exists

If you are using Process Builder or Visual Flow to add a User or Contact to a membership of some sort.  The main areas you’ll run into this are:

  • Campaign Members
  • Public Group Membership
  • Permission Set Assignment
  • Queue Membership

This can be avoided by doing Lookups of the existing memberships/assignments before doing the Record Create.  This can get difficult when you are dealing with multiple records, as there is a limit to how many Lookups you can do (and the ‘speed’ of doing this).

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!