How to lookup a value in one SFDC field (like Vlookup)

[Jo_Pitts1]

@SanfordWhiteman ,

how is it getting past the empty guard?  Is it because an undefined list is different to an empty list?

[SanfordWhiteman · Accepted solution]

---

how is it getting past the empty guard?  Is it because an undefined list is different to an empty list?

---

A nonexistent list (or any nonexistent reference) is short-circuited to null. And !null is always true.

Note: isEmpty() is never called in this case because there‘s nothing to call it on. So

#if( !$nonexistentThing.isEmpty() )

is effectively the same as

#if( !$nonexistentThing )

As usual, this digs into the details of what is true, what is false, and what is somewhere between the 2. Which is why you want your $references to always exist!

[Jo_Pitts1]

Yep - that is what I presumed was happening.

See... I really am learning 🙂

It is why I tend to be overly diligent in declaring my variables.  Of course, you can't do that with a cList.  

@michaelstancil , do you have all the fields you need selected in the tree to the right of the token editor?

[michaelstancil]

@Jo_Pitts1 @SanfordWhiteman The object is the correct one, and I've verified it does have data within SF, as well as Marketo, as I can see the values in each specific field when I apply the object as a list condition. Additionally, I am selecting all of the fields within the custom object when I'm in the token editor, as well as the zip from the opportunity. However, when I try and check for values in that custom object, or several other custom objects we have from SF, they all return as false.

#set( $HackermanHomesSold = !!${OtherCustomObject__cList})

That got me thinking that while I am able to see the fields as a list condition, there are no eligible contacts. Which then let me to think further that the issue is that the custom object is not associated with a lead/person/account, even though it exists under the contact level (and also as the account). Could this be the reason? This is how it's currently setup on the contact level:

[Jo_Pitts1]

@michaelstancil , you know your piece of code has a double not in it?

[michaelstancil]

@Jo_Pitts1 Oops! Thanks for catching!

[SanfordWhiteman · Accepted solution]

#set( $HackermanHomesSold = !!${OtherCustomObject__cList})

should be written

#set( $HackermanHomesSold = !!$OtherCustomObject__cList )

(don’t use curly braces inside operators, only for output)

but if it always sets $HackermanHomesSold to false, that means $OtherCustomObject__cList does not exist (not is empty, but does not exist , meaning implicitly null in Velocity).

---

That got me thinking that while I am able to see the fields as a list condition, there are no eligible contacts.

---

Then you would never expect Velocity to see the objects! Sometimes (i.e. 2nd-level+ objects) a Smart List filter can see objects but Velocity can’t. But never the other way around.

---

Which then let me to think further that the issue is that the custom object is not associated with a lead/person/account, even though it exists under the contact level (and also as the account).

---

If the person is a Lead, and the CO is only available via the Contact, then you absolutely would not see the objects.

[michaelstancil]

@SanfordWhiteman Got it on the operators vs. output!

---

---

Then you would never expect Velocity to see the objects! Sometimes (i.e. 2nd-level+ objects) a Smart List filter can see objects but Velocity can’t. But never the other way around.

---

If the person is a Lead, and the CO is only available via the Contact, then you absolutely would not see the objects.

---

Well, I think we figured out the why it's not working in the end. Good news is that I feel a lot better about this process in practice, so when this is configured correctly. I'm going to reach out to our team and see if we can put these values one step down.