Meta

One flow to rule them all.

Standard

Photo taken somewhere in SFDC HQ.

Recently, I found myself in a situation where I had a specific thing (Top Secret, Sorry!) I wanted my flow to do, but across multiple types of objects. As I built out my flow, I kept thinking, how can I build this so that it is a smarter flow? One that can accept multiple starting points? Well, to quote the announcer voice, “We have the technology, we the ability…”

But, let’s scooby doo intro back to the start…here is what I know:

The functionality I wanted to build involves doing a similar action against a lead, account and opportunity.

I can use a workflow to kick off this change

I can use a flow trigger to kick off the flow

Let’s start with the flow. What I actually did is not as important and the method, so a neat screen shot is not needed! The key piece here is that I have an input /output variable named “VarPassedRecordID”. Beyond that, really the ONLY other piece of the puzzle is a couple of decision points, one for each record. The decisions are all looking at the prefix of “VarPassedRecordID”. If the prefix of the ID matches the criteria, then the routing goes to the designated action

.

As a side note, I have started using this methodology in my criteria’s when I look for query results instead of looking for nulls.

The next step is the workflow’s. In my case, there are three workflows and each workflow kicks off a flow trigger. If you do not have flow triggers, go get them enabled! Flow triggers are great for these small jobs, though you could do this with the process builder as well…The flow triggers are themselves unremarkable. The only thing they are doing is passing the record ID over to the flows…wow, reading this one over, this is really boring functionality. Seriously, this is like trying to make a pair of needle nose pliers or a shop light sound exciting! However, like needle nose pliers or a good shop light, this is a very good piece of functionality to know about. You can add new object types in very easily and with out creating more and more flows.

The workflow kicks off a flow trigger, which passes over the record ID to the flow

The flow analyzes that data, and based on the prefix, directs the data down the right path

The only real “gotcha” to be aware of is that if you are using custom object, the record ID’s might have different prefixes based on your environments. You will especially find this true if you are migrating up the custom objects.

As always, let me know if there are any questions, comments or suggestions!