Normally, a lookup column points to just one table. Like, if you have a lookup called “Customer” on your Order table, it only points to the Customer table — nothing else.
A polymorphic lookup is different. It can point to more than one table at the same time. So instead of being locked into just one table, it gives you a choice of a few tables it’s allowed to connect to.
Simple example:
Think about the “Regarding” field you see on activities like Email, Phone Call, or Task. That field can point to an Account, a Contact, an Opportunity, or even a Case. It’s not locked into just one of them — it depends on what you pick when you’re creating that email or task.
Why it’s useful:
Without polymorphic lookups, you’d need a separate lookup column for every possible table, plus logic to figure out which one is filled in. That gets messy fast. Polymorphic lookups just let one field handle it all cleanly.
Interview tip: If asked: “Can you create a custom polymorphic lookup?” Say: “No, polymorphic lookups are only available in system tables like Customer, Owner, and Regarding. Custom lookups can only point to one table.”
