2

Here is an example from a 3rd party managed package of what I am currently calling a "Vanity Lookup" because it is totally redundant from an OOD/ERD perspective and I assume it is only for convenience:

Defining: QuoteLine->QuoteLineGroup->Quote

Vanity: QuoteLine->Quote

My example:

Defining: LicenseKey->Asset->Account

Vanity: LicenseKey->Account

My License Key custom object has a lookup to Asset. Simple right. Assets belong to Accounts though so there is an implied relationship from LicenseKey->Asset->Account. Fine. I know how to take advantage of that through SOQL queries and relationship report types. From an OOD or ERD perspective I'm done. But there is so much out-of-the-box goodness if I have a lookup from LicenseKey->Account too. I'm calling this a "vanity lookup" because it is a truly unnecessary and redundant relationship but it "looks better" when I get that free related list on my Accounts page (itemizing all of the License Keys for an Account) or my coworkers get to do easy Account->LicenseKey reporting without having to jump through the extra relationship.

Ultimately, I'm interested in the best practices for this technique. Is it discouraged? Is it as simple as marking the Vanity Lookup read-only and keeping it in sync with workflow? In an effort to keep my question specific I'll settle for the proper name so I can go search for the best practices myself... but hey, if you want to point me to a good article or share the best practices from your experience I'm all ears.

1
  • Best practice finding #1: use a trigger to keep the vanity/implied lookup in sync with the defining relationship. Workflow doesn't allow you to change custom lookup fields from field updates. The idea to allow this has been around for a while.
    – twamley
    Jan 8, 2013 at 6:21

3 Answers 3

2

If you're using it purely for on-screen information it's redundant and could be replaced with a formula field easily enough.

However I'd argue that in some situations this lookup would likely exist to benefit a developer, there could be circumstances where even though there is a connection between object A & B via some route, a direct lookup field could save a lot of headaches. In this scenario I'd just refer to it as a lookup.

1
  • It's mostly the automatic related list I want, which I can't get with just a formula. I'll take your explanation as a vote for this being an accepted practice anyways. Maybe this is so simple it doesn't need a name or a best practice guide. Where relationship #1 dictates relationship #2, keep #2 in sync with workflow or a trigger and call it a day.
    – twamley
    Jan 8, 2013 at 3:23
0

Transitive Lookup because A->B and B->C implies/requires A->C.

1
  • 2
    Just a pedantic point, but since SFDC allows multiple lookups between object types, if you have multiple lookups of B->C (e.g. B->C1 and B->C2), you don't know from looking at the "A" screen, holding lookup B and vanity lookup C, which B->C relationship is being navigated. That said, this sort of thing is done all the time in the implementations I've seen and I call them something like "implied lookup" or "automated lookup".
    – jkraybill
    Jan 8, 2013 at 5:32
0

New idea for when you're really after just the UI goodness and don't need it for reporting... Don't add the vanity/implied/automated lookup to the data model at all. Instead, in the UI, build and expose a lightning component that queries with the main relationship and shows related information. Saves on limits too. We're having success with this approach.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .