Add followers with Flows


Chatter (in my opinion) is one of the really neat features of salesforce, allowing users to follow records that might be important to them is just one of the “Killer Apps” of this functionality. Ironically enough, being that this is a social network, is the request for that one can just add followers automagically if  “X” condition is met. There are even a couple apps on the appexchange for that.

Automated Networking, Jumbo Shrimp, Stop / Keep Moving, OxyMoron

Automated Networking, Jumbo Shrimp, Stop / Keep Moving, OxyMoron

To me, this takes a bit of the social out of “social networking”, so I am going to sketch out a solution that is a bit more personable but still makes it easy to add a follower

In a nutshell, it goes a little something like this:

1)      Within a record, the current user feels that another user (or themselves) should be on the follow list

2)      The current user clicks a button. In this case, I have called it “Pied Piper”

3)      A flow is launched that does the following:

1. Looks up a user based information given

2.Attaches that user to the current record as a follower

As usual, I am just sketching going to provide the foundation for this functionality. The magic here is that you can flows to do some neat stuff like attaching multiple users, adding comments, tags, etc. You don’t have to add this stuff in, but I would encourage playing around with it to see what you can / can’t do. Also, a quick Caveat. I found that a user will have to have “Modify All” permissions on the object you are pushing this out to. 

That aside, now we get to the Nuts & Bolts of the matter. I have got a couple of components that I am going to be using:

  1. A visual flow
  2. A custom button driven by a URL
  3. A nice cup of Coffee (Optional, or not)

This flow function sounds exciting and awesome (Follower Updates, Magic!), but is really basic. There are four components to this flow, Entry screen, Record lookup, Record Create and the confirmation screen (optional). There is however a critical variable, varAccountID. This is the variable that houses the ID that is passed over via URL. Just be aware when you are building this out!

The Components

Salesforce Flows, How awesome

On the entry screen, there is a text box for entry of a person’s name. The text box value is passed to the Record Lookup. One of the easiest improvements would be making this multi search (name, ID, email), just something to keep in mind.

Search Box

The flow does a look up on name, and returns the userID.

2014-05-13 13_15_27-Flow Designer_ public_FlowFromFlow



Next up is the Record Create on the object Entity Subscription. In this case, the parentID is the accountID, but it can be anything. SubscriberID is just the UserId pulled above.

2014-05-13 12_49_55-Flow Designer_ public_FlowFromFlow

Once the record is created, there is a confirmation screen. This is an optional step, but something I like to do.


Now that I have a flow in place, I create a button (Pied Piper) on the account layout.

Pied Piper Button

1 story point was spent on the clever name

This button is nothing fancy, just running a hyperlink that will open up the flow AND push over the accountID of the record the user is currently in. I did add the retURL on the end so that instead of a loop, the user is returned to the accounts page.

Behind the Curtain

Just to reiterate, this is the foundational work. You could implement this into production and have something that works but it isn’t going to be awesome. Here are the required proof shots!


As always, questions or comments, hit me up!



Fun with Salesforce Flows – Parsing Multi Select Picklist fields


Fun with Flows – Parsing Data

I recently ran into a challenge while making / scripting / conjuring a fairly complex flow. I needed to get data out of a Multi Select Picklist (MSP) field for use later on in my flow. The google hive brain did not help at all…literally, I couldn’t find anything when googling on terms such as “salesforce visual flow parse”. Once I started googling ““salesforce parse” I got lots of results…for apex solutions.

So once again, I find myself faced with the following:

1)      Check my “Clicks Not Code” membership at the door and start down the apex path?

2)      Write some crazy formula field to do this work and then pass data back and forth?

3)      Put on my thinking cap and figure out a way to get this done with in a flow?

And as usual, I opt for #3.

First things first, I had to figure out what I had to work with. To do this, I extracted some data from my MSP fields and found that MSP’s store their data in a very logical way, ((“Value””SemiColon”)). What this means to me is that when I run the query on the object and push MSP field data to a variable, it is going to ONLY bring over the data that has been selected and it was going to show up as a text string. I had a hunch that the MSP would act this, but you know what they say, “Trust but verify”. This behavior also reinforced why I wanted to parse the data. Carrying around a full string like “Value 1; Value 2; Value 3” really reduces what you can do within flows.

Now that I know what I am working with, I can go about getting the data into the format I want. The quick synopsis is that I am going to:

1)      Create variable for the MSP Values

2)      Create decisions for each MSP Value

3)      String the decisions together

For this example, I have the MSP field “McDuck” that contains the values Huey, Louie, Dewey, Donald, Daisey and Scrooge. I want to separate out any selection into their own variable for use in other parts of my flow. Here are the steps I am going to run through (Visual in the PDF).

1)      Query “GetData” passes the values in the field “McDuck” to “varGotMcDuckData”


2)      The data in “varGotMcDuckData” is then ran through a number of decision setps.

     ParseHuey takes a look at “varGotMcDuckData” and if the data in that variable contains “Huey”, then populates “VarHuey” with “Huey”


      ParseDewey takes a look at “varGotMcDuckData” and if the data in that variable contains “Dewey”, then populates “VarDewey” with “Dewey”


3) Rinse, wash, repeat as needed!

There are a couple things important to keep in mind when doing this. The first is that these can get really big really quick. Don’t be afraid to use a subflow to do the dirty work (Future Topic!). Also keep in mind that once data gets passed into a variable, data is retained there until the flow stops. If you are going to have a multi-step process you need to build in a clean step where the variables are scrubbed of data.

Even though this is a fairly elaborate process, it really does go by quickly. The added benefit is that flows are recyclable, so if I ever had a need to parse out the McDucks in a flow anywhere, I could reference my parsing flows over and over and over again.