The Biggest Salesforce Admin Mistakes

These are the biggest Salesforce admin mistakes I’ve seen (or made 🙈) in no particular order.

>> Related: Debating Salesforce Leads vs Contacts <<

Developing directly in production

Do I have to state the obvious?  There is no “undo” button in production when you break something.  And you usually break something!  Most changes affect automation in ways we don’t expect.

The most common one I see is an admin creates a validation rule directly in production that doesn’t exist in the sandbox. Now somebody’s test code breaks and they “can’t deploy anything because the test code doesn’t work.” Do everything in a sandbox first, see how it affects the org – including running all Apex tests – and then move to production.

Refreshing sandboxes without asking

Don’t casually refresh sandboxes.  If you do, and there’s pending work, it’s just… gone. ☠️

How to prevent?

• Good:  Create an email thread with every person in the sandbox, and ask for written confirmation that you can refresh.  Dirt simple, but obviously subject to procrastinators.
• Better:  I’ve been really burned by this Salesforce admin mistake, so now I also backup my work in my own GitHub repository.
• Best:  Get serious about your change management and CI/CD practices. Implement a Dev/Test/Production sandbox structure.  Manage and resolve conflicts before you get to production. Potentially invest in a tool like Copado or Gearset, and take every change seriously.

Inconsistently naming campaigns and automation

Do future you a favor – use consistent naming conventions for both campaigns and automation.

• For campaigns, I generally use: [Start Date in YYYYMMDD Format]-[Type Abbreviation]-[Brief Description]
  • An example is 20220516-WC-My Awesome eBook
  • Here’s how I generally break down campaign types:
    • Web Content = WC
    • Web Form = WF
    • Webinar = WBR
    • List Import = LI
    • Event = EV
    • Nurture = NUR
    • Email Send = ES
    • Direct Mail = DM
    • Content Syndication = CS
    • Operational = OP
• For automation in Flow, I use:  [Object]-[Before/After Save]-[Brief Description]
  • An example is Campaign Member-After-Process UTMs
  • At a glance, I want to know what the Flow affects.  Is it doing same-object field updates only (Before Save), or potentially touching related records, or doing other notifications? (After Save)
  • Labeling automations also helps prevent overlapping or conflicting automation. I’ve seen an instance with 3 different conflicting automations updating the close date on Opportunities. 🤯

Mismatching labels and API names

Field labels and API names should be pretty similar. We admins often work with the API name… having a custom field labeled “Sales Team” with an API name of “Department__c” wastes a ton of time and sows a lot of confusion.  Just make it easy to find the thing you’re looking for.

Granting every request

A big part of being an admin is thinking like an architect, not an order taker.  Counter every request with “what’s the goal”?

I’m not saying it’s a kneejerk “no”, but admins are on the hook for finding simple, elegant solutions.  (And creating random fields for 0.7% of the database is… not the solution.)

Additional “architect” tips:

• Maintain a transparent Salesforce roadmap.  Not all projects are equally important.  Asking stakeholders to force-rank projects is a great way to stay focused on the important things.
• Create a backlog.  Good ideas don’t disappear, even if the answer is “not right now.”
• Track project volume, hours, complexity, and open/close dates.  Use Jira, Asana, internal Salesforce cases… even project managing in a stupid Excel doc is better than nothing. (Of course, reporting on the trends each quarter helps build your case for raises, new headcount, or agency support.)

Band-aid-ing sharing rules

Have more than 10 sharing rules for any object?  Unless you have an absolutely massive org, you probably need to restructure your hierarchy and users.  Just simplify the architecture and focus on more important projects.

Winging it with duplicates

When leads bypass the Marketing Automation Platform (i.e. direct Web-to-Lead), they create dupes in Salesforce.  Simply put, have a plan (or a tool) for resolving duplicates and selecting “the winner” thoughtfully.

🚨 Remember to exclude the Marketo sync user from de-duping rules. 🚨 Marketo needs to find and match records in Salesforce.  A de-dupe rule could ironically create a massive amount of dupes.

Hard-coding IDs

Don’t let me catch you doing this. Whether it’s in a validation rule to exempt the System Admin profile from a validation rule, or a piece of automation referencing a specific User/Record, do not use the ID. There is no guarantee that the ID will be the same between sandbox environments and production, and hard-coded IDs are just hard to read. Instead:

1. Reference a Name
2. Query for the data you need and reference the results returned in your query
3. Or use a custom label that you can update between environments. Always be thinking about making whatever you create as easy as possible for you and future admins to understand.

Which one is easier to understand?

AND(
ISBLANK(Some_Required_Field__c),
$User.ProfileId <> "00e4P000001SaiI"
)


or

AND(
ISBLANK(Some_Required_Field__c),
$Profile.Name <> "System Administrator"
)


Just don’t do it.

Letting everyone build reports

Salesforce isn’t a democracy.  Instances are dense, often have a lot of legacy crap, and data has to be interpreted with nuance.  It’s so common for individual users or teams to create reports with slightly different dimensions and filters.  One team references Lead Source, and another Campaign Source.  Soon we have conflicting narratives, we don’t trust the data… and things get really miserable.

Another really common offender is when using Leads and Contacts.  Reporting on simple questions like “how many MQLs did I have this month?” requires two different reports.  Every time.  When naive Salesforce users pull reports that look incomplete, they freak out and, again, make life miserable.

The solution?  Scope, create, and then lockdown org-wide no-touching Salesforce dashboards that track KPIs.

FAQs

What is a Salesforce validation rule?

A validation rule is a powerful feature that allows you to enforce data quality and consistency by specifying certain criteria that must be met before a record is saved. Validation rules are defined using a formula expression that evaluates to true or false.

What is an Apex test?

Apex tests, also known as unit tests, are written to ensure the robustness and correctness of Apex code (the programming language used on the Salesforce platform).

What’s an API name?

An API name, short for Application Programming Interface name, refers to a unique identifier or label assigned to various elements within a software system’s API. In the context of Salesforce or other platforms, the API name is used to uniquely identify and reference objects, fields, classes, methods, and other components accessible through the API.

What is de-duping mean?

“De-duping” is short for “deduplication,” and it refers to the process of identifying and eliminating duplicate or redundant records or data entries within a dataset or database.