Find your content:

Search form

You are here

Reusing Lookup Fields in Different Contexts


I'm trying to decide how to build my data model and I'm running into a typical situation involving lookup relationships. I'd love some thoughts on implications and best practices:

I have several different apps running in Salesforce on top of each other that have overlapping data needs for different purposes. For example:

  • In a case management app, a Contact has a lookup to another Contact who is their parent or guardian.
  • In a donor management context, a Contact has a lookup to another Contact who is their solicitor.

My question is: Should I create two different custom lookups, or use one lookup for both purposes?

Single Shared Lookup


  • Fewer custom relationship fields = simpler data model
  • Less likely to hit roll-up summary field limits
  • Easier to disaggregate functionality into different apps/sections.


  • Naming the field logically is hard - complicates training, reporting, and adoption
  • Ditto for description and help text

Two Different Lookups

These are basically the inverse of the other approach:


  • Language, definition, and training are easier


  • Data Model is more complicated, and greater risk of hitting reporting limits.

Attribution to: Benj

Possible Suggestion/Solution #1

I would vote for separate fields. From an administration standpoint, I think it will be easier to train and maintain dedicated fields. An example would be if you wanted to enforce a filter on the lookup based on Record Types (if you have separate ones for Solicitor vs. Guardian vs. other.) In addition, the related lists will be separate which would be helpful for your users; for instance instead of one list on the Contacts you could have "Dependents" for Guardians and "Clients" for Solicitors.

From a reporting standpoint I think it reduces complication and the potential for errors. You would not need to look for context to explain the data you're seeing, such as "oh, this is a Case Management Contact and I've been thinking it was Donor Management."

Attribution to: Mike Chale
This content is remixed from stackoverflow or stackexchange. Please visit

My Block Status

My Block Content