Often times I find myself in a situation where I need to reference a value from within a Visual Flow that is not on the Object I am working with. As we’ve talked about in a few of my recent posts, the biggest trick to bulkification is reducing the amount of queries that we are using. These queries count against our limits in Visual Flow and Process Builder. So, how does a Formula Field play a role into reducing our queries?
Lets say we’re in a brand new Org. We’re working on a Flow from the Contact Object, and we need to reference the Account Name for a naming convention on the Task we are going to create. The problem? It isn’t there for us. All we have is AccountId.
This is not a problem that you’re going to find in APEX, because APEX has Dot Notation. Unfortunately in Visual Flow we don’t have Dot Notation (or anything similar) at our disposal for us to navigate through a Lookup Field (vote for the idea here). Update: Gorav Seth pointed out that we can actually do this with a Fast Lookup, just not a Record Lookup.
However, we can use that AccountId to query the matching Account to get the Account Name. But, should we? Lets say that this Flow was being launched from a Button or Action, and there is no way that we’re going to ever have this running with another Flow or Process Builder. In that case, bulkification is not a factor (performance still is), and we probably are okay to add that extra query.
But, if you’re looking to bulkify your Flow, you’ll want to think twice about adding another query. It might be smarter to simply create a Text Formula Field on the Contact Object that gives us the Account Name value.
We obviously don’t want to start cluttering up our Contact Object with extra fields, but we do need to weigh the pros and cons of the situation. We won’t add this field to any Page Layouts, but is adding a field called Account Name going to confuse potential End Users that might see this in their List View or Reports? The answer to that depends on your Company or Client. In most cases the field you’re going to create will most likely be something that most End Users would overlook (if they saw it), but you do need to keep User Experience in mind.
As the Admin of my Developer Edition Org, I had a company-wide meeting and unanimously determined that there was not going to be a negative impact of adding an extra field called Account Name. When I went to create my Account Name Formula Field, I made sure that I left a very good description so that everyone why it was created and where it is being used.
After creating the Formula Field, we now have our Account Name available on the Contact Object without having to do an additional query.
And just like that, we have reduced a query in our Visual Flow and further bulkified our Contact Object!
NOTE: When dealing with Large Data Volumes (LDV), you want to avoid filtering your query with a formula field, as it can slow down the performance of your query (be it APEX, Reports, List Views, or Flow). In most situations we are not going to use our Formula Field in that way, but it is important to keep this concern mind.
IF you are looking up the contact w a fast lookup, you can in fact do cross object field references
https://developer.salesforce.com/docs/atlas.en-us.salesforce_vpm_guide.meta/salesforce_vpm_guide/vpm_designer_crossobject_reference_simple.htm
It just doesnt work w/ record lookup elements
LikeLike
Thanks for sharing Gorav! I’ve made an update in the post to include that, I appreciate the insight!
LikeLike