Autolaunched Flow – Salesforce Sidekick

How to use Case Comments with Communities in the Service Console Feed View & Salesforce1

August 29, 2016October 24, 2016David Litton10 Comments

This past week I had someone who is looking to use Case Comments in the Service Cloud, but wanted it to be listed as an Action in the Feed. I thought it would be a good use case of many different tools within Salesforce being used together. I am looking at possibly doing this with code and basing it off this post, but for now I figured that I’de show you how without code. Let me be clear that if you’re not using a Community that you can simply use the Internal Comments field instead without having to do anything. The only negative of going with this solution is that you’re not going to have your Case Comment Chatter Post visible until your Chatter feed is refreshed, but that is something that also happens with the Internal Comments field. The Case Comment record is visible instantly. And this works nicely with Salesforce1. With that said, let’s jump right in!

Automation Overview:

Inputs for Case Comment received (Action)
Process Builder triggered (Pass inputs into Visual Flow)
Case Comment created in Flow

For this solution we have two different options in how we can do it architecturally:

Record Create – Create new Custom Object
Record Create – Create new Task Record
Record Update – Use Custom Fields on Account/Opportunity

For me, because of not wanting to further complicate the Task Object and not wanting to add excess fields to the Case Object, I’m going to go with option 1 and create a new Custom Object.

How will we build this?

Create the Case Comment Extension Object
Create our Visual Flow to create the Case Comment
Create our Process Builder to launch the Visual Flow
Create our Action on the Case

For this solution we have two different options in how we can do it architecturally:

Record Create – Create new Custom Object
Record Create – Create new Task Record
Record Update – Use Custom Fields on Account/Opportunity

For me, because of not wanting to further complicate the Task Object and not wanting to add excess fields to the Case Object, I’m going to go with option 1 and create a new Custom Object.

What fields do we need create in this Custom Object?

Auto Number
Case (Master-Detail)
Comment (Long Text Area)
Public (Checkbox) Note: this only applies if you have a Customer Community.

CaseCommentExtensionObject

Let’s get our Flow created first since we can’t Activate the Process Builder without it (Setup | Create | Workflows & Approvals | Flows).

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

We now need to create the variables we will use to create the Case Comment.

Case Id

CaseCommentParentIdVariable

IsPrimary (This is a BOOLEAN, not Text)

CaseCommentIsPublishedVariable

CommentBody

CaseCommentBodyVariable

Lets make sure everything is correctly mapped inside our Record Create.

CaseCommentCreation

Great! So lets hit OK and set this as our Starting Element.

SetAsStartElementCaseComment

Now lets drag in our Record Delete. This is so that we don’t add useless data into Salesforce.

RecordDeleteDrag

Create a variable for the Record Id of the Custom Object record we just created, when our Action is used.

var_CaseCommentExtensionId

Map it in our Record Delete.

DeleteCaseCommentExtension

Connect the elements together to finish our Flow.

FinishedFlow

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

SaveCaseCommentFlow

ActivateCaseCommentFlow

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)

CaseCommentExtensionPBCreation

We want the Process Builder to fire on our Custom Object that we created, Case Comment Extension, and we want it to fire only when a record is created.

CaseCommentExtensionPB1

We don’t need to set any criteria here, but to be safe let’s just make sure that we have a Case ID and Comment before proceeding.

CaseCommentExtensionPB2

Now we need to map the variables in our Flow to the Values in the Custom Object, using the Type Reference.

CaseCommentExtensionPB3

Hit Save, then Activate your Process Builder. Now, lets navigate to go create our Action.

CaseCommentActionNewButton

Keep it on the default, Create a Record, and select Case Comment Extension (our Custom Object we created earlier).

CaseCommentAction1

Let’s make sure we turn off the Create Feed Item, so we don’t spam the Chatter Feed since the Case Comment itself will cause a Feed Item to be created. Also, make sure we add in a nice Success Message and custom Icon to make the action look sharp!

CaseCommentAction2

Remove the Case Field and drag Public and Comment into the Action’s Page Layout. Make sure you require the Comment field.

CaseCommentAction3

It will give you a small popup warning you about not having the Case field on the Layout, but you can ignore it and move on.

CaseCommentAction4

We now need to setup a Predefined Field Value for our Case field.

CaseCommentAction5

Set Case.Id to our custom Case field.

CaseCommentAction6

Now all that is left is for us to update our layout(s)!

CaseCommentActionToLayout

And with that, lets take a look at the finished product!

Five Best Practices for Building a Clean Visual Flow

August 1, 2016October 24, 2016David Litton2 Comments

We’ve all been there, where you’re learning to write your first Visual Flow. The main thing we’re focused on is just making sure that it is functional. That’s fine while you are in your Sandbox developing, but once you’ve got it working correctly you need to make sure your Flow follows these five best practices.

Elements are Organized

One of the top rules for writing code is using proper indentation. David Liu (SFDC99) is known for his love (or OCD) of clean code. Visual Flow’s equivalent to indentation is the alignment of the elements into a clean format. Think of it like you’re having company over – you would make sure you cleaned your house up before they arrived.

Your Flow should be very easy for you to follow the Flow Elements from start to finish without having to strain your eyes. Keeping it clean also lets your Flow be easier to make future updates to it. You don’t have to take apart your Flow to make sure you didn’t miss anything on your update. So, be sure you spend the extra minute or two to make sure your Flow is sharp looking!

Bad

Messy Flow

Good

Sharp Flow

Naming Convention

In the developer realm, camel Case is the standard. In Flow, we’re stepping into the developer world without really having to write code. It obviously isn’t required that you use camel Case as your naming convention, but it is important that you follow a consistent naming convention. If you don’t, your Flow will be much harder to read.

Variable Names

In addition to your naming conventions, you need to make sure your variable names make sense. I have opened up way too many Flows that use variable names that are not clear. If someone has to do some detective work to figure out what your variable is doing, you need to rethink your variable naming. Variable naming can often be hard to do correctly, because you have to summarize the function of the variable into a small concise variable.

Do: CaseId — Don’t: RecordId

Why? RecordId is very generic and does not tell me what Object it is referring to. I would have to go find where the value was assigned to see the Object it is the Id for. CaseId is clear and I don’t have to do any research to figure out what it is.

Fault Messages

When your Flow fails its important for everyone to be alerted. If you’re a Solo Admin, then you can technically get away without using a Fault Message, because Salesforce’s Email Alert will go to you. However, if you have more than one person developing in your Org, this is a requirement! By setting up a Fault Message, you can easily alert all of the Admins and Developers of the issue.

It is also important to use multiple Fault Messages inside your Flow. You’re able to customize the Email being sent out to provide specific information that pertains to that particular part of your Flow. This will help you as you troubleshoot your Flow.

Fault Message

Descriptions

Make sure you use Descriptions in your Visual Flow. This goes along with having your Flow Elements all aligned and easy to read. You want your Flow to be easily digestible. It is important to not write blatantly obvious Descriptions, just to write them. You want to make your Descriptions helpful.

Anytime you have to do something unique inside your Flow you should include a Description to explain what, and more importantly why. An example would be when you use a Formula in your Flow.

Recap: Think long term when you’re building your Flows (or anything). Just like you want to create a good User Experience for your End Users, make sure you create a good one for the Admins & Developers that are maintaining the Org. None of these best practices require a significant amount of time to follow, and the benefits of having a clean Flow will be worth the extra effort! And if you’re still reading, make sure you check out my The 6 Most Common Visual Flow Errors to Avoid.

How to work with Related Records in Process Builder Criteria

July 11, 2016October 24, 2016David LittonLeave a comment

When Process Builder first came out, the lack of error messages made it hard to adopt. I have noticed from looking at the Salesforce Answers Community, confusion with Process Builder errors is a very common. In this post, we will cover one of the most common mistakes for someone learning Process Builder – how to work with related records.

What do I mean by related records?

Anything that is referenced through a Lookup Field on an Object (including System fields like Created By).

When you’re working inside Process builder, you’ll see a chevron next to any related object that you can navigate to. This lets you then reference the fields of that Object in your Criteria and Actions.

RelatedRecords

This works like a charm, until you decide to have a Process Builder reference a Lookup Field that is not populated (so the value is null).

Yikes! We never want to see that error stopping an End User from saving a record! What happened? Salesforce will tell you in your Fault message (emailed), the variable “hasn’t been set or assigned.” What does that really mean though?

You were trying to reference a related record, but your Lookup Field does not have a value or record in it. This isn’t documented very well, and is an easy mistake almost everyone will make as they learn to use Process Builder. This is a new problem for Admins, because we do not run into this issue with Formula Fields and Field Updates (in a Workflow Rule). And, this is a serious problem because it actually can affect an End User’s ability to make a new record and/or edit an existing record.

So now that we know the problem, how do we fix it?

Check for Null
Formula Field

Checking for Null is the approach that I prefer to go with. Either one can technically work, but I choose to keep my Objects as simple as possible and avoid adding excess fields.

For our example, lets say that we wanted to run some automation for our Opportunity when the Primary Campaign is Type = Trade Show. We’d first need to make sure that our Opportunity actually has a Campaign associated to it, otherwise we’d get that failed to execute the flow error. So, how do we do it?

Campaign ID > the Related Record, ability to reference Campaign Fields.

Campaign ID the Campaign Lookup Field on the Opportunity.

That means that the Campaign ID Field houses the value of the Lookup. Which means we can check to see if there actually is a value!

SelectCampaignId

CheckforNull

Now, we are able to add the rest of our conditions that reference our related Campaign record.

Note – we must to check for Is Null BEFORE we reference the related record’s fields. Salesforce checks our criteria from Top to Bottom.

We can now reference fields on related records in Process Builder because we first validated that we had a related record.

Understanding how to write Process Builder Criteria

June 6, 2016October 24, 2016David Litton5 Comments

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.

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

Conditions are met
Formula evaluates to true
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

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!

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!

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

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

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.

No criteria – just execute the actions!

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!

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:

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

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

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

May 23, 2016October 24, 2016David LittonLeave a comment

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:

Account Record Meets Criteria – Process Builder triggered (Pass inputs into Visual Flow)
Flow Finds ALL Contacts Associated to Account
Flow Finds ALL Campaign Memberships for ALL Contacts
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

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

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

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

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!

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

April 25, 2016October 24, 2016David Litton1 Comment

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:

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

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

We will be creating:

Premier Support [User Field – Checkbox]
Flow to run our logic
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).

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_PermissionSetAssignmentId – The Id of the Permission Set Assignment, if the User has been assigned the Permission Set already.

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

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.

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.

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.

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.

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.

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.

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.

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

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

April 18, 2016October 24, 2016David Litton12 Comments

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 Create a Conditional Auto Number

March 28, 2016October 24, 2016David Litton15 Comments

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:

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

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

Custom Object
Custom Metadata
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.

CreateClientNumber

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.

FindAutoNumber

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!

CreateClientNumberFlowSave

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

February 15, 2016October 24, 2016David Litton2 Comments

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

TargetNameOrID

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

February 7, 2016October 24, 2016David Litton2 Comments

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.

PittyFool AwkwardLookup

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