When to add a new object

Just because you can add as many fields as you want to an object - it doesn't mean you should. The power of a relational database comes in being able to see related objects in the page view - so you don't want to add too many extra fields with lookups in the record detail itself.

If you want to see a lot of different fields from different objects in one place, create a report!

But what do you do you do if, for example, you want to start keeping track of tools that are being used at different occurrences?  Do you add fields to keep track of the tools?

NO.   To fully leverage the power of a relational database you would create a new object:  Tools.

You need a plan before you start.

You need a plan before you start.

Effective Databases aren't built by constructing things on the fly:

  • You wouldn't build a house by grabbing a hammer and starting to put all walls
  • You'd want a blueprint  a plan.  You need to consider the architecture.
  • If you build a house by constructing one room,  and then later add another room,  and another ... the plumbing is never going to work!!!!

Don't start anything until you've thought through the big picture!

How's it going to work together?

What do you need in this new object and what objects will it be related to?

What if we were creating a "tools" object to keep track of the tools we check-out to occurrences of volunteer opportunities?

What if we were creating a "tools" object to keep track of the tools we check-out to occurrences of volunteer opportunities?

Start by thinking through all the kinds of fields you'll want to track.  

Work with your organization to make sure you have a complete list of everything that will be needed BEFORE you start to create the new object and all its fields and its page layout!

Here's just a few things we might want in a TOOLS object:

  • Name of the Tool
  • Give each individual tool its own unique number?
  • Location of the tool  (a lookup to a location record)
  • Who has the tool ( a lookup to a contact record)
  • Date tool was borrowed?
  • Date tool is due back?
  • Condition of the tool
  • Cost of the tool?
  • The occurrence the tool is being used by (a lookup to the occurrence record)
  • The quantity of the tool

OR, do we want to give each tool its own record number with a unqiue number?  If so we would need a TOOL ID number - and we would be able to run a report on how many tools were shovels.

We need to make decisions on how we want to manage our tool bank as a business process -- and THEN figure out what fields are needed in the object!

Learn About Building Data Models in Salesforce

Trailhead has a great module that explains how to build new objects in Salesforce.  

Click here to read about Data Modeling


Add your comment

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.