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.


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:


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


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


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


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



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


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


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



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


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.


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


Connect the elements together to finish our Flow.


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



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)


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.


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!


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


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




How to Post to Chatter in Visual Flow

Some people might think, “Why would I want to Post to Chatter in Visual Flow when I can do that in Process Builder’s nice Chatter Post UI?”.  Well, the answer is pretty simple.  You’re only able to post to records related to the one that triggered your Process Builder to fire.  By doing our Chatter Post in Visual Flow, we are now able to @mention any User and any Record in Salesforce (that we have chatter enabled on).

Disclaimer: You are able to use a Record Create on the FeedItem Object to create a Chatter Post.  This is often times the route you’ll want to go, as there are more features that you can take advantage of that this Post to Chatter Static Action doesn’t have.  However, this Post to Chatter does not count against any of your Flow Limits (besides the 2,000 used element limit).  So, if you’re in a situation where your close to your limits, try using this action!

Depending on how many Flows, Quick Actions, and Email Alerts you have in your Salesforce, you might not notice the Static Actions section at the bottom of your Palette.  In here you’ll find a list of all three Static Actions.  We are going to be using Post to Chatter.

Great, we found our Post to Chatter, so lets drag it onto our Flow’s Canvas.

Drag Post to Chatter.jpg

Now, this is the cool part of a Static Action Post to Chatter is the same as an Email Alert.  I only need the Record ID for me to make the post, it doesn’t matter where or how I triggered this Flow!  It is important to note that this isn’t the only use for our Post to Chatter‘s Target Name or ID.  We have the option to post to a specific User or Group (just like we can in Process Builder).


Note: If you insert the Username or Chatter Group’s Name into the Target Name or ID reference, you will need to include the Target Type to let Salesforce know whether they need to match that to a User or Group.  This could potentially save you a query if you’re close to your limits and you don’t already have that ID in your Flow.

Now, the next piece we get to is the Message.  This is the body or description of our Chatter Post.  I am going to strongly suggest that you always use a Text Template when doing anything with words in Flow.  So, that is exactly what we are going to do here to build out our Chatter Post!

Post to Chatter Text Template

If you notice, we have a different way of @mentioning Users or Groups inside of a Flow’s Chatter Message.  We must stick to the format of @ [ {User/Group ID} ] for our @mention to work properly.  DO NOT use the formatted text option, as you’ll see the actual HTML code show up in your Message.  The formatted text should only be used with Screens (places the User interacts with in your Flow).

Post to Chatter Finished Text Template

The great thing about using the Text Templates is that we can easily reference our Variables using the section that says Select resource.  This can come in handy when you want to bring in other related fields like the Opportunity Amount or Close Date into your Message.  You can either type the variable or other resource into the search box, or click on the dropdown arrow to have every listed by resource.

Selecting Resource.jpg


You also have the ability to add in additional parameters to your Post to Chatter.

  • Community ID
    • Only valid if you are posting to a User or Chatter Group that belongs to a Salesforce Community
    • ID of the Community you are referencing
  • Target Type
    • Required only if you are using the Username or Chatter Group Name in the Target Name or ID parameter
    • Valid Values
      • User
      • Group
  • Visibility
    • Only matter if you have a Salesforce Community enabled
    • Valid Values
      • allUsers
      • internalUsers

Notice what is not there – the ability to do it as a specific User.  This will always be written from the User who triggered the Flow.

Additional Chatter Options

On the Outputs side of our Post to Chatter we can see that we have the option to grab our Feed Item ID (the ID of the Chatter Post we create with this element).  Now, this can be great if you want to add comments or reference it elsewhere.  95% of the time, you’ll probably be ignoring this feature.

Setting FeedItem Id

Now all that is left is to press OK and map this Post to Chatter to the part of your Flow you need it to send from.  Pretty simple and easy to use!


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.


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!


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


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.

Find Queue

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


Our finished Record Lookup will look like this:

Find Queue 2

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.

Add Decision.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.


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.


Save Queue Flow.jpg

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.

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.


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


My recommendation is to use this solution by Doug instead of following the steps below:


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