This post was last updated on 11/21/23.

Introduction

Time and again, we at Kicksaw have conversations with clients who are complaining about a system that’s slow, hard to use, and generally confusing. They come to us begging for help because their opportunities/accounts/etc. have become bloated and unusable. They’ve spent years adding crap to Salesforce and they don’t have the architectural skills to get out of the mess they’re in now due to so many dependencies.

The bad news for our customers is that fixing this will likely take some time and be expensive. We could come up with a quick fix where we run FIELD TRIP, cut out any fields that aren’t absolutely necessary, and plan to revisit the problem down the road. Multiply this problem across accounts, leads, contacts, and the myriad of other objects they’ve created, though, and the reality is that there’s a fundamental problem at the core of it all that needs to be addressed:

What exactly is an [INSERT OBJECT HERE]?

What’s the problem?

Most SFDC admins are non-technical. That’s the beauty of Salesforce: a person with little-to-no real development experience can usually build out a system that supports any type of business. This, though, is also its downside. A person with little-to-no development experience architecting a system that your company relies on to do business is…dangerous, to say the least. Tracking bookings, renewals, marketing campaigns, implementations, customer health, etc. in a system built by someone who doesn’t understand the fundamentals of system architecture is a recipe for disaster.

The good news is that these skills can be learned! The bad news is that 99% of admins are never going to learn them. Why? Because it takes time and effort, and you’ve got a board meeting next week, but we need a field right now to track some esoteric metric in a report that will never be re-visisted again. Sound familiar? Don’t worry — that’s where we come in!

What is an object, anyways?

Startup employees are often stretched thin and wearing too many hats to really focus on everything that they should be focusing on. One of the most important questions we ask our customers when they run into the bloated-objects issue is to take a step back and tell us what a given object represents.

Typically, our conversations go something like this:

Kicksaw: So, how do you define an opportunity?

Customer: Well, we use them to track deals in progress, renewals and pilots.

Kicksaw: Cool. So, you probably track things like term dates, deal size, and general notes about the deal.

Customer: Yes…but we also track which products they’re using, their CRM, key contact, our SDR that set the meeting, the competitors we’re up against, the start/end dates of the pilot, how much we’ve spent on flights to visit, our executive sponsor…

Kicksaw: I see. Let me stop you right there.

The problem here is not that the client is tracking this information — some of it can be critical! The problem is that the client is using a given object to store information that doesn’t pertain to that object. In object-oriented programming, this is called a God Object, and it must be avoided in order to prevent object bloat.

An object in Salesforce (as well as in any other application) should be tightly defined and store the absolute minimum amount of information necessary in order to be effective. Objects should also be unique and identifiably different from other objects. For example, consider how contacts related to accounts. They are fundamentally different, even though they are tightly associated with one another.

Accounts vs. Contacts: A lesson in unique objects

An account in Salesforce represents a given business entity or company. It should have unique identifiers such as its name, website, headquarters address, and employee count.

A contact in Salesforce represents an employee or person related to a company. It makes sense, then, that this object would contain information such as this person’s name, email address, phone number, and the account they are associated with.

We often see customers try to store information about a given contact on the account object. For example, they’ll create fields such as:

• Billing Contact Name
• Billing Contact Email
• Billing Contact Phone
• Sales Contact Name
• Sales Contact Email
• Sales Contact Phone

As a new admin, this approach might seem innocuous. Your A/R team needs to know who to contact on a given account when they’re past due on an invoice, so you put that information on account object. But what happens if the billing contact leaves and a new one is hired? You now have three pieces of data that need to be updated, and there’s no guarantee that the three fields are in sync.

The same goes for the sales contact. The fields in the list above represent data that really should live on a contact object stored on the account.

Another risk this approach presents is that data you’re putting onto your account object already lives somewhere else. It’s on the given contact, and what if the sales contact and the billing contact are the same person? Now you’ve triplicated the data for no good reason.

When creating an object, as yourself how you can most narrowly define what this object is meant to represent. Then ask if the data this field contains actually applies to this specific object. Some additional questions and consideration are: 

• Does Salesforce already have an object that allows me to track this information? If so, it is best practice to use the Salesforce object.
• How do we need to report on this data? By itself or in relation to other objects?
• Think of fields in an object as attributes or characteristics that help to describe the object — this will help clarify your strategy.

The answers to these questions will help you avoid the dreaded object bloat.

A note on junction objects

If an account represents a company and a contact represents a person, how should you define a person’s role within a company? After all, they may have only one role, or they may have ten. The scalable way to represent the role of a person (contact) working for a given account is to use a junction object to connect accounts and contacts. SFDC offers this object out-of-the-box, and it’s called a contact role. It’s really a junction between an account and a contact.

Another great example of a junction object is competitors. Let’s say you are selling to an account called Nike, and you want to understand their competitor. Many companies will add an account lookup and populate the value with Adidas. This seems simple, but there is one glaring problem. Nike also competes with Reebok, Puma, and New Balance, just to name a few brands.

To manage this data efficiently, create a junction object called a competitor. This competitor links Nike to Adidas and can also link Adidas back to Nike. If you had opted for a lookup field, that information would only really be reportable on the Nike account, but if you then look at the Adidas object, there’s no guarantee that Nike would show up, never mind the hundred other brands.

Parting thoughts

As an SFDC admin, avoid making decisions such as simply adding a lookup field. Just because an action is easy doesn’t mean it’s optimal. You don’t want to limit your ability to scale down the road. It can be very hard to know what you don’t know, when it comes to Salesforce administration, but that’s where consultants such as Kicksaw come in.

Short of hiring a consultant, you as an administrator need to understand how objects work, how they relate to one another, and, most importantly, what they truly represent. Doing this will help you build better systems that are cleaner, simpler to navigate, and are designed to scale.

‍