Salesforce Marketing Cloud: The naming convention to end all naming conventions

What’s in a name? When it comes to Salesforce Marketing Cloud, there’s a lot.

Photo by Andrea Piacquadio via Pexels

How should we name and organize our assets? We consultants who work in Salesforce Marketing Cloud (SFMC) field this question a lot. And in the context of our clients’ big, technical SFMC projects, it can feel like an afterthought, something of secondary importance, to be mulled after the big fish — exciting data integrations, automations, custom solutions, etc.—are fried. So, how should you name things? We think we’ve got the ideal naming convention — the naming convention to end all naming conventions — and you can have it, including a free download. Read on to learn more.

Little-known secret

The little-known secret of SFMC operations is that your naming convention is your destiny. Having the wrong one (or worse, none at all) means searching and scrolling endlessly in the platform. It means sometimes never finding that old campaign or query that would save the day. It means occasionally breaking something. The pain of poor naming is multiplied for SFMC instances operated by many staffers, each adding and updating assets. Shiver. Having the right naming convention means airtight operations, easy access to everything, and smooth deployments from sandbox to production (if you’re doing that). Also, good naming conventions are a nod to those coming after you (internal staff or partner), making for a quicker orientation period. Yes: removing ambiguity in terminology is a big time-saver.

Origin story

Your blog post author is as dyslexic as the day is long. Mostly that’s no big deal… I probably read slower than you, but otherwise life hums along just fine. One area where it’s not fine: when scanning a list of items or names — e.g., data extensions in SFMC — where the names are long and similar-looking. Things can get real confounding, real quick. That’s what sparked the quest to come up with a simple, easy-to-use naming convention in SFMC: a client’s complicated, multistep automation that was composed of a dozen SQL queries and target data extensions where each data extension in the progressive build had painfully similar names, making it just plain hard to keep track of each asset. There had to be a better way: one where each query and target data extension had a deterministic name, eliminating any possibility of connecting the wrong assets to each other or misunderstanding what this data extension housed versus that one.

Naming: The Ten Commandments

Before we talk about naming, let’s establish ground rules. These are the parameters that define how the ideal convention would work. In a nod to the Agile methodology in which SFMC practitioners often work, let’s make them user stories.

As an SFMC user working in the application, I can…

1. Identify what any asset in SFMC is or does just by looking at it; at least some of the name must be descriptive rather than arbitrary.
2. Apply my names to any asset: journey, email, SMS, content block, automation, SQL activity, script activity, other activity, or anything else.
3. Never confuse any two assets; if I tell an SFMC teammate, “Check out data extension ______,” that person knows what I mean and where to find it.
4. Deploy an asset across business units, keeping the name the same where appropriate.
5. Quickly surface the asset I want within a list/folder using native SFMC search boxes.
6. Keep track of these assets, enabling me to see a description of the asset and its “story” if any.
7. Rely on related assets to have the near-same name, so I know what goes with what, e.g., an SQL activity and its target data extension are eponymous.
8. Instantly know which folder houses my asset — whether I’m looking at folders in Content Builder, Automation Studio, Contact Builder, etc.
9. NOT have to click five levels deep into those folders to find my asset—that’s a pain.
10. Do all this with minimal added work, so my flow doesn’t slow.

Introducing: The Deli Counter Ticket Giver

If you read the foregoing list closely, you’ll see that SFMC can’t be organized without a companion document — something that assigns identifiers to SFMC assets, catalogs those assignments for easy reference, and lets the SFMC user document some notes. That companion is a simple spreadsheet; we call it the Deli Counter Ticket Giver (DCTG) because, like the noble red device at your local deli counter, it proffers a unique identifier the moment you need it. Nobody else has that number.

Deli counter ticket giver. Photo by Mike Motzart

Step 1

Before we can hatch your DCTG spreadsheet, we need to zoom out. Ponder the full breadth of all tactics you’re using in SFMC. Indeed, categorization is the first step and the linchpin of staying organized: you must bucket your various communications tactics and SFMC assets together. This exercise shouldn’t hurt too much, but can be an initial struggle for mature accounts. So, how many buckets? Because this is a numbering system, you want a maximum of 10; you’ll see why. A medical nonprofit might have these categories:

• Testing/development assets
• Triggered messages
• Newsletters
• Blasts to donors
• Blasts to patients
• Employee messages
• Birthday campaigns
• Other sends
• System-wide technical assets
• Package Manager for moving from sandbox to production

Step 2

Like the real deli device, we’ll be working with arbitrary numbers, with one assigned to each asset. So, depending on the scale of your operation, you’ll next choose the scale of categories that will accommodate, say, the next four years of your SFMC operations. For example, if you’ll execute roughly 100 instances of each tactic above over the next few years, you can choose a three-digit scale, that is, where the 100s buckets will occupy DCTG tickets 100–199. If it’s more like 1,000 or even 10,000 installments of a tactic, then just choose 1000–1999 or 10000–19999. Using that scale, you arbitrarily assign each category into a bucket of number ranges like this — conveniently, these become your folder names throughout SFMC:

• 0000 Testing
• 1000 Triggered
• 2000 Newsletters
• 3000 Donor blasts
• 4000 Patient blasts
• 5000 Employee
• 6000 Birthday
• 7000 Other
• 8000 Systemwide
• 9000 Packages

Step 3

Using your favored spreadsheet software, hatch your DCTG. Where? Excel is near-universal on laptops; Google Sheets offers a super-slick user interface. Power users will find bliss in Microsoft SharePoint Lists. Whatever you choose, create a worksheet, and in the left column, use formulas or fill-down to create one row for each number in that bucket’s range. These are the prefixes for each asset’s name. In Row 1, call this column Name; for each new asset, you’ll populate a row with a descriptive name next to the next-available number. (The number is just a prefix.) This is you pulling a new ticket from the red device at the deli (i.e., for a new campaign, or query, or content block, etc.). Name the next few columns for each type of asset you work with in SFMC. Generally these are:

• Email
• Content Block
• Journey
• Data Extension
• Filtered Data Extension
• Automation
• SQL Activity
• Data Extract Activity
• File Transfer Activity
• Other Activity

Finally, add a Notes column after the asset types. Populate each cell with a checkbox; you’ll check this box to indicate that this name in SFMC is that kind of asset. It should look like this:

First sheet of your DCTG

Note: The example above was built in Google Sheets, but if your organization uses Excel, you can download a pre-built DCTG here; the only difference is that, instead of clicking checkboxes, you’ll input any text in the asset columns (e.g., “1”), after which an embedded conditional formatting rule will darken the box, like this:

DCTG in Excel with dark boxes indicating selection

Step 4

Now simply duplicate that worksheet for each bucket, and name each worksheet per bucket. You’ll update the prefix numbers in your Name column to match that bucket’s number series—bonus points for using a different color scheme for each bucket, serving as a visual cue of which bucket you’re in. Here’s what it looks like to scroll through 10 sheets:

Completed DCTG — all the sheets

Bring it all together: DCTG in action

Using the DCTG in a real workflow is quick and easy. Example: You’re tasked with creating an email and related assets for this month’s Matching donor grant email. In our system, that would sit in the 3000s bucket, so let’s add it to that worksheet. The assets we need are an email, query, data extension, automation, and journey. We’ll also package it in Package Manager, to move this from sandbox to production. And to further demonstrate the system, let’s say the new email requires a novel “bulleted list” content block that we’ll create at this time; it’ll be repurposed throughout SFMC, making it an 8000s Systemwide asset.

Using the DCTG in a workflow

Now, from the worksheet, just copy the full name for our new 3002 asset — i.e., 3002 Matching donor grant — June 2024 — and paste it when creating each of the five assets in SFMC. See below how, in Content Builder, SQL Activities, Data Extensions, Automation Studio, and Journey Builder, the folder names are consistent, and these related assets are named the same name everywhere.

Using the DCTG name for each asset

Power users leveraging Package Manager to move assets across business units can use the DCTG to give a discrete name to each package they deploy, with a distinct, package-specific identifier each time a particular asset (or entire campaign) deploys. This is where the “Notes” section of the DCTG shines: with a quick descriptor, you soon accumulate a priceless history/log of what you did for each deployment — very helpful for triggered campaigns. Here’s an example that depicts adding a fourth deployment of the 1001 email:

Using the DCTG with Package Manager

What’s most lovable about the DCTG is how it shrinks your workload when hunting down assets. Let’s say you want the New Jersey VIP donor list. A quick scan of your DCTG tells you that’s asset 3018. When you’re faced with pages-upon-pages of data extensions, you need merely to type 3018, then enter. It’s not just faster; gone is the mental overhead of reading each of many similar-looking assets and comparing them against your brain’s snapshot of what its hunting. Just type and click.

DCTG identifiers make searching fast.

Bonus conventions and conclusion

Two other good naming practices not specific to the DCTG: (1) I beg you, resist any temptation to put the asset type in the name of an asset — like a journey called Welcome Journey — a crime of redundancy on par with ATM machine or cheese quesadilla; and, (2) in SQL, add to the end of each query a quick, three-line comment indicating this query’s name, target, and action (e.g., append, update, overwrite), which can save time and confusion, and help when working with queries pasted in a text editor—Slack or elsewhere.

In my experience, the only drawback of the DCTG is how much I depend on it — such that, when I’m air-dropped into a fusty old SFMC instance without it, I daydream of greener pastures. If your organization isn’t ready to adopt this tool, there’s help to be had in the form of powerful SFMC add-ons like DESelect and SFMC Companion. And while we declare the DCTG to be “the naming convention to end all naming conventions,” there are of course many ways to tackle this issue. Comment below with your favorite, and if you’d like to invoke the myriad powers Slalom consultants can bring to your SFMC or Salesforce, get in touch.

Slalom is a next-generation professional services company creating value at the intersection of business, technology, and humanity. Learn more and reach out today.