In an early post I talked about how, in Visual Flow, to referencing fields on a related object record without having to waste a Lookup to fetch that record. In this post I’m going to expand on that just a bit…and point out a problem area to be aware of.
What I want to expand on is that it is not only possible to look up to an immediately related object record, but you can also cross over that object to another related object record to get the value of a field.
In this example I have an sObject variable which has a lookup to an Account (“HHAcct__c”). The HH Account is a sub-account of another account. So this formula returns the Name of the “Grandparent” account–it looks past the account to the parent account and gets the value from a field on that record.
The only two tricks to making this work are 1) you have to know the full “dot” path because the flow “intellisense” will only be able to get you to a field on the current object so you’re going to have to type it out yourself, and 2) in order to assign the cross-object field value to something (like a variable or another field), you have to put it into a formula.
You can also use cross-object references in screen display fields and text templates. You just can’t use them in an Assignment or a Decision element.
What About Cross-Object References on Custom Objects?
‘Still works. And here is an interesting little tidbit: The syntax of the “dot” path isn’t picky. In other words, these two statements will work just fine:
CustObj__c.Account.Parent.Name = CustObj__r.Account.Parent.Name
(See how one has “__c” and one has “__r“? The Flow doesn’t seem to really care which syntax you use.)
There is something really weird that can happens with certain circumstances so be sure you’re aware of this as you go about your day going hog-wild adding cross-object references to your flows all willy-nilly.
In certain circumstances you will NOT get accurate information!
That bears repeating. There are certain circumstances where Salesforce can’t seem to get the correct value of the field you’re reaching out to.
That happens when you are reaching out to formula fields that have an IF or CASE statement.
Here are the circumstances which will yield inaccurate results:
- The field you are referencing is a formula field (it doesn’t matter what type, text, number, date, whatever)
- That formula has an IF or CASE statement
So if you are reaching out to a formula field with an IF or CASE statement you will not get accurate results, which is really an unhappy place (trust me, I know!).
What you’ll get instead is the default for the IF statement (the “false” return value), and who knows what for the CASE statement (I haven’t tested the CASE statement extensively enough to be able to tell you what it will do).
What About Other Formula Fields?
Formula fields that do not contain an IF or CASE statement seem to evaluate perfectly fine and return the expected result. For instance, if you have a formula field that combines text from a couple fields (eg. Firstname & ” ” & Lastname) you’ll get the accurate combined text. If you have a formula field that references the value on a related record field (eg. Account.Opportunity.Name) you’ll also get an accurate value.
Is There a Work-Around?
There is only one workaround that I’ve detected so far…you have to use up another Lookup to retrieve that record(s) you want.
Bummer. All coolness evaporated. Poof.
So go forth bravely and use the heck out of those cross-object references…just be sure you’re watching for those IF/CASE formula field references!