The Most Critical Skill of a Salesforce Admin: Defining an Object

The Most Critical Skill of a Salesforce Admin: Defining an Object

  • kyle
  • 17 Jan 2019

Time and again we 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 don't have the architectural skills to get out of this mess 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 and the reality is that there's a fundamental problem that needs to be addressed:

- What 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 build out a system that supports any type of business. That's also its downside. Let me reiterate: A person with little-to-no development experience is architecting a system that you rely on for your business. You track bookings, renewals, marketing campaigns, implementations, customer health, etc., etc. and you have a person who doesn't understand the fundamentals of system architecture.

The good thing is that these skills can be learned but the bad part 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 and we need a field to track some esoteric metric in a report that'll never be revisisted again.

What is an object anyways?

We realize that startup employees are stretched thin and are wearing too many hats to really focus on everything they should be. One of the most important things we ask our customers when they run into the problem of bloated objects is to take a step back and tell me what a given object represents.

Typically, conversations go 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, etc., etc., etc.....

The problem here is not that they're tracking this information, some of it can be critical. It's that they're using a given object to store information that doesn't pertain to that object. In Object-Oriented Programming this would be called a God Object and it must be avoided.

From our perspective, an object in Salesforce(as well as any other application) should be tightly defined and store the absolute minimum amount of information necessary to be effective. Objects should also be unique and identifiably different from other objects. An example of this is how Contacts related to Accounts.

Real example

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

A Contact in Salesforce represents an employee or related person to a company. It would make sense that this object would contain information like their name, email address, phone number and the Account they are associated with.

Often, we'll see customers trying to store information about a given contact on the Account. 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 tactic seems innocuous. Our AR team needs to know who to contact on a given account when they're past due on an invoice. 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. Same goes for the sales contact. This is a very common issue we see: Data that really should live on the contact is stored on the account. Another challenge this presents is the fact that that data already lives somewhere; on a given contact and the Sales Contact and Billing contact could be the same person. Now you've triplicated the data for no real reason.

The question to ask yourself when creating an object is this:

- How can I define what this object is meant to represent?

The question to ask yourself when creating this field is:

- Does the data this field contains apply to this specific object?

If an account represents a company and a contact represents a person, how do we define a person's role within a company? They may have one role of ten. The proper, and more scalable way to represent a role of a person working for a given account would be 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. Seems simple, however, there is one glaring problem: Nike also competes with Reebok, Puma and New Balance in addition to the hundred or so other brands.

What's the solution?

The way you'd fix this situation is to create a junction object called a Competitor. The competitor would link Nike to Adidas and would also link Adidas back to Nike. If you had gone with the simple method of a lookup field that information would only really be reportable on the Nike account but if you go Adidas there's no guarantee that Nike would show up, much less the hundred other brands.

This is a common example we see of SFDC admins making decisions because they're easy but are far from optimal. There's no chance that creating this field will bring down the system but it limits your ability to scale down the road.

To sum up the last 1,000 words it's critical that you as an administrator understand how objects work, how they relate and more importantly what they specifically represent. Doing this will help you build better systems that are cleaner, simpler to navigate and are designed for scale.