Understanding how to write Process Builder Criteria

I am working on a mini-series related to understanding Bulkification (related to Process Builder and Visual Flow).   So, you’re going to see a theme of posts like this and Building your Process Builder for Optimum Performance and Bulkification where I focus on some design considerations with Process Builder and Flow.  The reason behind these posts are because Process Builder and Flow are extremely powerful tools that give those previously developer-only powers to the masses.  And as we all know… with great power comes great responsibility!  So, lets do our part to make sure that we build our Process Builders and Flows in a way that would not cause developers headaches.  I’ll cover the basics of the different types of criteria, and then go over why it matters that you take building criteria seriously.

spiderman1.jpg

When setting the criteria for our Process Builder to fire, our options are:

  1. Conditions are met
  2. Formula evaluates to true
  3. No criteria – just execute the actions!

Lets dive deeper into each of these and talk about when and why would use them, and some of the common mistakes that are made around these.

Conditions are met

criteriapb.jpg

Using this as our criteria gives us a few more options than what we used to have with Workflow Rules criteria.  Now, we have operators like Is changed and Is null that were previously unavailable to us.  Outside of those new options it is essentially just a cleaner UI.  Don’t forget about the ability to make your Value a Formula (see condition #3), you can use awesome functions like PRIORVALUE and grab in cool System things like your Custom Settings!  Speaking of, Jennifer Lee has a great post on using Custom Settings in Process Builder that is a must read for anyone not familiar with Custom Metadata or Custom Settings!

Conditions.jpg

So we can pretty much do pretty much everything inside this criteria option… but what are the pitfalls that we will run into?

Forgetting to check the Advanced checkbox.

I really wish that Salesforce didn’t hide this section, it needs to be front and center!  I feel like this is one of the biggest errors that people make when building a Process Builder.  It is often overlooked until you’ve got a Process Builder that is creating a record or sending an email, and you realize that you’ve just had six emails get sent out to a Client!criteriaadvanced.jpg

Using Is changed

While I absolutely LOVE this operator that Salesforce gave us within Process Builder, the fact of the matter is I have seen tons of Success Community questions where people get stuck on this.  It isn’t documented very well that Is changed will ONLY run on Updates.  This will not run on Create.  That means, you’re up a creek without a paddle if you’re trying to build your Process Builder to only fire when a value changes, but also have it work if that field has been filled out on create.  If anyone has a clever way that they’ve found to bypass this issue, I’de love to hear it.

Formula evaluates to true

criteriapb2.jpg

While not as simple as the conditions are met option, this gives us the ability to do everything that we would want to do.  The problem is that this often is more fragile than the rest.

API Field Name Changes

This option unfortunately will NOT update your formula if you have to change the field name.  Keep this in mind, because just about everywhere else in the UI this is something we’re accustomed to.  You will however be greeted with a lovely error message anytime you try to Clone ur Update your Process Builder

errormsg.jpg

Is changed for new records works!! kinda…

Here is a simple example of how you could use the formula evaluates to run on new records and still run ischanged on updates.

We essentially have separated our criteria into On record create and On any updates.

(ISNEW() && NOT(ISBLANK(field)) || ISCHANGED(field)

In my below example I only have to use ISNEW() because the Case Status is always filled out.

ischanged.jpg

No criteria – just execute the actions!

criteriapb3.jpg

This should not be used unless you have a very good reason.  Just because we have a simple action does a Record Update and nothing else does not mean that we want it to always fire on every edit.  This means that every single edit our Process Builder is firing.  How many situations can you think of that actually require a Process Builder to fire every single time?  Don’t be a lazy Admin and use this option just because you can!

Why does this matter?

Because of how Salesforce ‘bulkifies’ our Process Builders and Flow!

bulk.jpg

https://releasenotes.docs.salesforce.com/en-us/winter16/release-notes/rn_forcecom_process_bulkification.htm

The issue is that as we continue to customize an Object with more and more Process Builders and Flows you keep adding to the string length!  Remember that every simple Record Update in your Process Builder, no matter how simple, counts as an actual query that will be added into that ‘bucket’.  Previously with Workflow Rules you never had to worry about those simple Field Updates running on every edit of the record, but now as we try to keep our Process Builders and Flows bulkified it becomes an issue!

By fully understanding our Process Builder’s criteria (and using it correctly), we are able to cut back on the extraneous actions.  This results in two big things:

  1. Reduced process time when you hit Create or Edit a record
  2. You’re more bulkified due to a decreased the number of queries

Which means you’re now the hero of your Org!

hero.jpg

How to use a Loop inside a Loop (in Flow)

This past week I saw multiple comments about using a Loops, and one in particular around doing a Loop inside of another Loop.  It is a pretty rare thing that you’ll do with Flow, because of the limits that you’re going to be dealing with, it is very easy to hit a wall with this solution.  Your second Loop is very inefficient, and has to run for every record that is found in the first Loop (which means a Fast Lookup/Query).  This SOQL queries limitation has been improved, prior to writing this blog I thought the limit was 50, but it seems Salesforce recently improved that limitation to 100.

So, keep your limits in mind when you begin to architect a solution like this.  Sometimes it can’t simply be done safely with Flow and you need to move to Apex.

limitsflow

Note: I know that you can add a Formula Field that brings the AccountID to the Campaign Member, but this is a simple example that gets the main point across.

Business Case:

  • When we lose a Client and mark them as a Former Client we want to remove all of their Contacts from all of their Campaigns

Process Overview:

  1. Account Record Meets Criteria – Process Builder triggered (Pass inputs into Visual Flow)
  2. Flow Finds ALL Contacts Associated to Account
  3. Flow Finds ALL Campaign Memberships for ALL Contacts
  4. Flow Deletes ALL Campaign Memberships for ALL Contacts

 

Now, because I’ve already done a post on Fast Lookups and Loops, I am not going to really dive into the individual pieces of this Flow.  I am going to give an outline of what each Element is doing, but I will only be focusing on the areas that are key to understanding how you can use a Loop inside of a Loop.

First, we are going to start out our Flow by looking for ALL of the Contacts related to our Account.  All we need to do is pass in our Account ID into the Flow so that we have that as a Filter.

First Element.jpg

FastLookup1.jpg

Next, we need to now Loop between each of the Contacts that we have found with our Fast Lookup, so to do that we need to drag in our Loop.

Second Element.jpg

Loop1.jpg

Now, this gets us to our Second Fast Lookup, which is where the magic happens.  In here, we simply need to take a step back and think about what we are trying to filter.  In this case I am trying to find all of the Campaign Memberships associated to a particular Contact (so that I can add them to a collection and then eventually delete them).  So, in my Fast Lookup I should be using my Looped Variable to bring in the Contact’s ID.

Third Element.jpg

FL in Loop 0.jpg

FL in Loop 1.jpg

Just like that, we are dynamically filtering this Fast Lookup for each Contact that comes into our Loop!  Pretty simple, right?  All that is left for us now is to setup our next Loop and talk about what we are doing there.

For each Campaign Membership our Contact has, we will be sending them through our next Loop.

Fourth Element.jpg

CampaignMember.jpg

Next, we want to assign the Loop Variable to another SObject Variable, our first step in creating a SObject Collection Variable.

Fifth Element.jpg

Assignment1

Now, we want to assign the SObject Variable to our SObject Collection Variable.

Sixth Element

Assignment2

So we just completed our Loop for the Campaign Memberships!  Awesome!  But, what happens when that Looped Contact has no more Campaign Memberships for us to Loop through?  This is where I’ve seen many people mess up there Flows (including myself every once and a while!), because there is typically a lot going around.  You need to correctly map your second/inside Loop to your first/outside Loop!  This is where we then repeat the process for every Contact that we had in our first Fast Lookup.

Loop to Loop.jpg

Great!  Now, all that is left is for us to determine what happens at the end of our First Loop.  In this scenario we want are sending them to a Fast Delete to get removed in bulk!

Seventh Element

FastDelete.jpg

Great, we are all set!  All that is left for us is to build our Process Builder to launch this Flow.

RECAP:  Loops inside of Loops are powerful features that can let bend the limits of Flow.  These should be used sparingly when you know your inside Loop won’t be used in a high enough volume that you’ll hit a transaction limitation with your Flow.  If you’re getting not confident that you’re going to stay away from that limitation, you should consider building this in Apex instead.  As you could imagine with a scenario like the one above, if we had any Accounts with upwards of 100+ Contacts we would be in some trouble! Beware of the limits!

The “One Process Builder Per Object” Design Pattern

Ever since the Summer ’16 release notes dropped, the Salesforce Community has been going ecstatic over the one and only Process Builder improvement.  The Community is so excited with this one feature, that I have not seen anyone complain about Process Builder only had one improvement.  The reason is this improvement is a game changer in the Process Builder world, and it will change the way that we build our Process Builders.

ReleaseNotesImageEvalNextCriteria

Note: Evaluate the Next Criteria has one limitation currently.  It doesn’t work with Scheduled Actions (which makes sense).  So, if your Process Builder has a Criteria that includes Scheduled Actions, you’re out of luck for continuing any further down the Process Builder (and that particular Process won’t really apply to this Blog Post).  So keep in mind during this post that any Process Builder with a Schedule Action can’t be included.

Unable to do Scheduled Actions

One Process Builder to Rule them All!

TheOneRing.jpg

You’re probably asking yourself why would we want to build an extremely long Process Builder?  This idea comes from attempting to mirror the Apex Trigger best practice and design pattern.  Yes, there are additional benefits to this design pattern with Apex as opposed to Process Builder, but the main points still ring true.

#1 – Keep it Simple

No longer do you need to search through tons of Process Builders trying to understand what all is going on behind the scenes.  You’ve got all of your logic in one spot for you to look at (excluding Scheduled Actions).  Heck, Salesforce even mentioned how it makes it easier in the release notes!

release notes.jpg

#2 – Control Your Order of Execution

pemdas.jpg

So, just like with your Order of Operations, it is important to be able to know what order you execute Process Builder actions.  However, unlike the Order of Operations where we can follow a consistent process every time… with Process Builder we don’t know which order our Process Builders will execute in.  If we have 15 different Process Builders on the Cases Object, then we have no control over what order they will be executed.  It is quite scary when you realize you’ve got zero control over the order your Process Builders run in!

With executing multiple criteria in a single Process Builder we are now able to consolidate all of our Process Builders into just ONE.  And, in our one Process Builder we can drag and drop our actions around into the desired Order of Execution.

For a quick summary, creating one Process Builder to rule them all will allow you to simplify your Process Builders for each Object, and will allow you to have consistency in the way your actions are fired.  Do you have to do this?  No, there is nothing stopping you from continuing to build Process Builders in the same fashion that we previously did.  But, I would ask you to consider thinking about incorporating this design pattern into your Orgs once it becomes available.

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!