So I have an entire post written and ready to post on my upcoming Wine App but I realized that Dev Org be damned, I want to try and explain how I think about creating objects and managing object relationships.  It can be intimidating to wrap your head around them at first and I want to do my best to explain how I figure out if something should be a different object or not when building out a custom solution.

What is Object Oriented Programming?

I could spend lots of time explaining this, but there are people smarter than me who can explain it better

What is Object Oriented in Salesforce?

To me, and to most non-developers, this is about creating objects and relationships between objects that make sense.  There is more but if you aren’t programming, stick to this mindset.

Look at Accounts and Contacts for example, they are different objects because Accounts have many employees, and Accounts don’t respond to emails

  • Accounts
    • Typically have an address
    • Often still (for whatever reason) accept faxes
    • Have revenues
  • Contacts
    • Inherit the address from the account
    • Have and hopefully respond to emails
    • Are an expense of the Account

If they were the same object you could do it one of two ways

  1. Have an account with a bunch of fields for Contact 1, Contact 2, Contact 3, etc, etc.  The problem with this is that if you planned for 10 contacts, and a company shows up with 11 Contacts, you have to create more fields.  Not very scaleable
  2. Have a contact record for each contact, and be forced to type in all the Account information (Address, Fax, Revenues) EVERY TIME you create a contact.  By having them as two objects you can select the Account Name and inherit the rest of the fields

What about when you are designing from scratch?

This is where I’m pulling it back to using your Developer Org to get it figured out.  Why?  Because no one will see you screw up.  You can plan with your dev org at night, get it perfect, and then show up to work and look like a superGenius.  Worst case you delete things and try again

So my general rule to figure out if they should be separate objects is:

  • Can there be more than one record almost exactly the same?

If so, then it’s probably time for a parent-child relationship

Let’s look at a few examples

Chevrolet is a car maker
  • They make many kinds of cars.  They have a head office, shareholders, debt, revenues, advertisements, other stuff
    • Each kind of car has slight differences each year and also slightly different models.  This would probably be the same level to me – you would have “2013 CRV EX”, “2013 CRV EX-L” at the same level.  If you really needed to you could split them out but I don’t see the gain.  Each car has a trim package, pricing, discounts, expected fuel economy
      • Multiple people will buy each one of these models.  Each person will pay a certain price, buy with a certain number of KM (Miles for those south of the border) already on the car, potentially take a loan, have an address, etc.  These metrics are very different from the car itself.  They are also independent of the car – so they are records in a separate object

So imagine everything there being one object

  1. Having Chevrolet as the object just isn’t reasonable.  You have millions of people buying every year.  Having millions of fields that are all essentially duplicates of each other on one record makes no sense.
  2. Having the person buying as the object and record isn’t feasible either.  It would take them days to buy a car because the rep would be keying in data for all three objects every time – buyer, model, manufacturer and all the fields related to each.
Nike makes a lot of things
  • Nike has a head office, probably a few head offices
    • Nike will have different departments for Running, Golf, Hockey (do they still make hockey gear?), Baseball, etc each with their own advertising budgets, staffing requirements, long term plans, org charts, etc
      • Each department will have their own series of products for sale.  There are probably 1000s of different shoe styles out there.
        • Each product is bought by many, many different people for too much money because they like brand names
Golf Courses
  • A golf course has many attributes – # of holes, hasDrivingRange, hasRestaurant, hasBeer, isOpen, Revenue Goals, Address
    • A golf course is open so many days a year.  Florida is all year, up here we have snow
      • Each day has many tee times available.  The number of tee times varies by day because of sunrise and sunset, and frost
        • Each tee time will ideally be filled by 4 people, but could be less, they may or may not want carts.
          • **You might want to have this as a junction object with Contacts so that you can track how often a certain person plays your course.

That last part can become relevant really quickly.  I know many courses that just type in my name when I call, not caring who I am, when I come, anything like that.  Other course ask for my email the first time, and then they log how often I come.  I’ve got one that right away allowed me to opt out of BS marketing, but requested that they still be allowed to send me coupons.  I said yes and a few times a year I get a “Come Back!” email with a half off tee time coupon.  Keeps me coming back, all thanks to object oriented programming!


I go back to my picture again at the top of the article.  If I’m wondering if I need multiple objects, I ask myself if there can be many records that share a lot of the same attributes because they are related through an “overarching” unifying element.  Sound complex?  I know, but it really isn’t.

  • The Corvette and Cadillac have a unifying element of being owned by Chevrolet
  • Lettuce and Fennel are very different, but they are both a vegetable.  Vegetables have fibre and are colourful.  Grocery Stores have vegetables…and meat, and dairy.  See what I did there?  (Hint: I worked my way back up a series of objects)
  • Countries have cities.  Cities have restaurants and hotels – either different objects or different record types for businesses.  Both restaurants and hotels have customers.

How do you know when to use objects?

Use a child object if:

  • You catch yourself keying in the same values for 5 fields every time you are creating a record
    • Create a parent object and inherit the fields instead
  • You catch yourself adding 8 fields that are exactly the same to the point where you are naming them something like
    • Person 1
    • Person 1 Address
    • Person 2
    • Person 2 Address
    • Person 3
    • Person 3 Address
    • Person 4
    • Person 4 Address
  • You catch yourself creating a multi-select picklist
    • Just…don’t….do….it
    • They are horrible
    • You know what sucks?  Multi-select picklists
  • You say to yourself or get a request from someone saying – “You know this record would be perfect if we could have a field that is a table”.
    • Queue alarm bells there.  You will get that request
  • When you wonder why your reporting isn’t very good
    • Hint: Because the text values you keyed in for Person 1, Person 2, Person 3, Person 4 are in no way unified between multiple parent objects.  Salesforce has no reason to assume that they are the same person across multiple records

Where to next

Well next I’ve got a Wine App starting out, but if you missed my hints early on in the article through links, read my article on object relationships, which will compliment this one well and help fill in some blanks



Share Button