Salesforce, Python, SQL, & other ways to put your data where you need it

Need event music? 🎸

Live and recorded jazz, pop, and meditative music for your virtual conference / Zoom wedding / yoga class / private party with quality sound and a smooth technical experience

Salesforce Custom Metadata vs. Custom Objects

18 Oct 2018 🔖 salesforce custom metadata tutorials
💬 EN ( Lire cet article en français )

Table of Contents

A colleague, new to Salesforce, asked me the difference between “custom metadata” and “custom objects” for storing “configuration and validation” information in Salesforce.

My answer is:

  • Custom metadata if you can. Salesforce says so.
    (And it survives sandbox refreshes!)

  • Data tables (custom objects) if you truly need it to be part of your data
    (e.g. people will want to include it, hyperlinked to other data, in reports)

How I decided

When I wrote an Apex trigger that determined which User should “own” each “Admissions Application” in our org, I ended up splitting the configuration data in two.

Here’s why.

Custom Metadata

Used for a table that helps Apex code ask, “Who does this?”

  • key: the code for a graduate degree we offer
  • value: a username responsible for recruiting people to that graduate degree

Data (Custom Objects)

Used for a list of U.S. states, their full spellings, and fields with “lookup” links to the User table indicating who does what work for that state.

  • There was strong demand to generate native Salesforce reports per User showing all the states they’re responsible for and the high schools in those states. It made sense to ensure that the “high school” table could have a “lookup” field to this “states” table.
  • Custom metadata can have “master-detail” and “lookup” relational links to other custom metadata, but it can’t link to ordinary data.
    • This meant we needed to store the the “states” as data (custom objects), even though we would also be using it as configuration information for Apex triggers.

UI & editability considerations

I’ll let you in on a dirty little secret about another reason I used data tables (“custom objects”) for most of the Undergraduate Admissions counselor assignment configuration data.

Undergraduate Admissions tweaks their “recruiter assignment” business rules several times a year. The real-world configuration data for their business is a lot more complex than a simple “list of U.S. states.”

I’ll be honest: Salesforce’s user interfaces for hand-editing, viewing, and bulk-editing data are a lot more end-user-friendly than their user interfaces for the same operations on custom metadata, and setting granular “edit” permissions is a lot more sysadmin-friendly for data. I wanted to make sure end users, not sysadmins, were the ones whose time was spent tweaking the configuration several times a year!

I was thoroughly scolded at Dreamforce. Actually, I stand by my decision to use “data” tables, because there truly is a business need to report on the configuration data alongside normal data. But … building your own user interfaces (typically using Lightning Components) to help end users edit custom metadata was a big theme. You have been warned:

  1. Dan Appleman’s “Build Awesome Configuration Pages with Lightning Components & Custom Metadata”
  2. Gustavo Melendez & Krystian Charubin’s “Crafting Flexible APIs in Apex Using Custom Metadata”
  3. Beth Breisness & Randi Wilson’s “Create Guided User Experiences for Managing ISV Custom Metadata”
--- ---