Salesforce Best Practices for Admins: Do’s and Don’ts

Share this article...

The Salesforce Admin holds the keys to the castle, giving them admin superhero powers. However, as Uncle Ben told his nephew Peter Parker, aka Spiderman, “With great power comes great responsibility.” That’s why performing the role of Salesforce Admin is so critical to an organization.

This article provides an essential list of Do’s and Don’ts for Salesforce Admins.

This guide is broken into categories, as admins have wide-ranging responsibilities:

  • System Performance
  • General System Administration
  • Change Management
  • Troubleshooting
  • Security & Access
  • App Building
  • Working with your team
  • Staying Current with Salesforce

System Performance

Having a healthy and efficient Salesforce Org is critically important for both the speed of your Org and its long-term health.

  • Do perform the Salesforce Health Check on your Org and take the necessary recommended actions under the ‘Fix Risks’ button.
  • Do check the boxes for “Enabling Separate Loading of Related Lists” for faster page rendering in the Setup > User Interface.
  • Don’t leave ‘Release Updates’ tasks to the last minute (formerly Critical Updates).
  • Don’t ignore those pesky update and maintenance emails from Salesforce.
  • Don’t create Technical Debt:
    • Remove metadata components you create for solutions or testing.
    • Proactively tackle your Org’s existing technical debt!

General System Administration

This category includes foundational Salesforce Do’s and Don’ts for an Admin’s day-to-day job.

  • Do know which edition and instance of Salesforce your Org is on as different editions have varying functionality and governor limits. You can find out more here.
  • Do know the differences between the types of licenses – plus how many licenses are available in your org. Find out more about licenses here.
  • Do review and update your Org’s User Interface settings:
  • Do backup your Salesforce Data and Metadata regularly:
    • There are several options available for data backup, including the Salesforce weekly export.
    • Consider a 3rd party App like OwnBackup for frequent exports of both data and metadata.
  • Do enable Einstein Search as this is now generally available at no extra cost. Setup is simple, just enable it and let your Users feed Einstein!
  • Don’t forget to test all your work thoroughly. Test in a sandbox or developer environment, then test again in Production.
  • Don’t assign the ‘System Admin’ profile to Users:
    • Only 1 to 2 Users in your Org (typically the System Admins) should have this profile, plus automated Integration Users could also have the profile of System Admin.
    • No one else should have this Profile. You should use a Cloned profile to create a similar profile (without Modify All, and other unnecessary permissions).
  • Don’t guess and don’t assume:
    • As a Salesforce Admin, it’s better to ask before doing if you are unsure.
    • Don’t put yourself in a situation where you need to beg for forgiveness later!
  • Don’t do anything stupid 😊

Change Management

In this section, we’ll explore some key Do’s and Don’ts for deploying components and related tasks. In most Orgs, it’s recommended to use lower-environment sandboxes for configuration and development, and then deploy to Production.

  • Do communicate all deployment changes from one environment to another:
    • Tools like Slack and Teams are helpful for this. Create a deployment channel.
  • Do create a Rollback Sandbox before doing a major deployment to Production:
    • Do this by creating a Developer Sandbox and make a copy of Production metadata.
  • Do use Agile over Waterfall.
  • Do use themes and colors for different Sandboxes:
    • This helps visually differentiate from Production and other Orgs, and helps avoid configuring something in Production by accident. Whoops, sorry.
  • Do organize your sandboxes for testing/QA:
    • Many Orgs use Development Sandboxes>QA/Testing Sandbox >Production. A Staging sandbox is helpful too!
    • Consider 3rd party solutions for Release Management and other DevOps tasks (such as Copado, Flosum).
  • Do Add, Edit, and Configure only certain items in Production:
    • Editing and updating ‘record-level’ data in Production is correct.
    • Creating and editing Reports and Dashboards can be done in Production.
    • Adding ‘Available fields by lookup’ to Report Types can be done in Production.
    • Adding Public Group members in Production is a must. The members are considered data, and they don’t deploy.
    • Enabling features, like Digital Experiences, will need to be done manually in each environment, including Production. Same with Uploading packages.
    • Plus, other items that don’t deploy in changesets (such as adding an Org-wide Address, API name changes, etc.)
  • Don’t develop in Production:
    • It’s a best practice to configure and develop in lower environments; then deploy to Production (except for the items listed above).
    • APEX needs to be deployed from a lower environment and run through unit tests.
  • Don’t refresh a sandbox without telling everyone using that sandbox:
    • Allow Users to move their work out of the sandbox first.
    • If you don’t tell everyone – beware! Consider this your warning.
  • Don’t forget to add to Record Types for a picklist change to the change set.


As a Salesforce Admin you’ll have plenty of opportunity to troubleshoot issues. Here’s a list of Do’s and Don’ts to help in this often-challenging endeavor.

  • Do ask users for the URL/Link to the record, for troubleshooting issues with records.
  • Do have Users provide a screengrab of the error/issue, and steps to reproduce the error.
  • Do become familiar with the first three digits of Salesforce Record IDs for the most common objects:
    • The 15/18-digit Record IDs always start with the following three digits: 001 Account, 003 Contact, 005 User, 006 Opportunity, 500 Case, OOQ Lead.
  • Do know where to find the 15-or-18 digit Salesforce Record Id within a URL:
  • Do ‘Login As-User’ to assist with troubleshooting, and recreate the issue. Oftentimes, an issue is user training (to be polite), not a system bug.
  • Do check the Object-level Validations, if there is a custom error message:
    • Admins can View the ‘Error Message Text’ for all your Validation Rules under each object (and match to the User’s screengrab error).
    • If the error message is a standard error message, try to Google the exact error message to get more information, or check Trailhead communities (see below).
  • Do become friends with the ‘Debug Log’ to figure out why automation is not working as expected. The debug log will let you know where and why an Approval Processes or other automation is not working as expected.
  • Do use the new ‘Sharing Hierarchy’ button in LEX (from Summer ’21) to help with record sharing issues. This is especially helpful to see which Users/Groups a record is shared to, and how/why it is shared with them.
  • Do use the Trailblazer Answers Community to find answers to your questions. These communities can be used to look up previously asked questions, or a User can post a new question.
  • Do know how to raise a Case to Salesforce Help Desk, plus Chat with Salesforce:
  • Do consider using the Case object for internal tracking of Bugs, Enhancement Requests, and more.
  • Don’t ignore the ‘email deliverability’ setting in Production and Sandboxes: this setting is a common cause of errors in sandboxes.
  • Don’t forget to prioritize requests.
  • Don’t try to troubleshoot issues until enough information has been provided. If you don’t understand the issue, ask for clarification.
  • Don’t troubleshoot only using one browser. For some issues, you’ll want to rule out an issue being browser-related.
  • Don’t forget to check the Page Layout assignment for issues where Page layouts are missing fields or displaying a different layout for Users:
    • Remember, the Page Layout assignment is the combination of a User’s Profile and Record Type.

Security & Access

In this section we’ll review some Do’s and Don’ts for OWD, Profiles, Permission Sets, FLS, and more.

  • Do become familiar with your organization’s OWD (Org-Wide Defaults):
    • Do know your Org’s sharing settings for your most commonly used objects. This information is listed under Setup>Sharing Settings.
    • Understand the differences between: Public, Private, Controlled by Parent.
  • Do know which Profiles and Permissions Sets your organization regularly uses:
    • Do use Permission Sets to give special access for Objects/Fields and System Permissions (it is best practice to use Permissions Sets over creating a brand new Profile).
  • Do use Field-Level Security (FLS) to control fields being displayed on Page Layouts.
  • Do use Validation Rules
  • Don’t provide ‘Public Read/Write’ for standard or custom objects as your Org-Wide-Defaults (unless restricting access is unnecessary). Instead, provide less access (Read only or Private) through the OWD, and provide additional record access through sharing rules or other access methods.
  • Don’t forget about governor limits that you may run into. For example, an Org only gets 50 criteria-based sharing rules per object. Another limit is only 10 Dynamic Dashboards per Org (for most).

App Building

For this section, we’ll explore App Building Do’s and Don’ts, plus related activities.

  • Do use good naming conventions for new objects, fields, and other metadata.
    • Keep it simple and match the object/field label to the API name.
  • Do use the ‘Description’ field.
  • Do provide Read/Write access to the System Admin Profile for all new fields.
  • Do use the Schema Builder to see the relationships between objects.
  • Do create a Developer sandbox in your org for your own development, testing, and configuration.
  • Do create a personal Developer sandbox, outside your org, to do certain testing in a clean environment.
  • Do consider using Dynamic Forms.
  • Do use Field Tracking on your objects to track data changes:
    • Salesforce allows 20 fields to be tracked per object – so organizations should use this feature on their important fields. Note: more fields are available to be tracked, with a premium subscription to Salesforce Shield.
    • Put the Tracking History as a Related List on the Record Page. You can also report on these fields.
  • Do use the ‘View Setup Audit Trail’ to see what metadata changes have taken place and by whom.
  • Don’t add a new Record Type to an Object unless required:
    • Adding a new Record Type should be your last option to meet a use case.
    • With new Salesforce features like Dynamic Forms and Related List Filters on Page Layouts, extra Record Types become even less necessary.
  • Don’t use the same Field Label on a single object (with having different API):
    • This becomes an issue building your Page Layouts because admins see field labels, not APIs, and won’t be able to differentiate between the fields.
    • This is also an issue with Report Builder – you don’t want your user’s trying to work out which is the correct field because they have the same name!
  • Don’t use the same Object Label for a new custom object that is already a label for a standard object (i.e. don’t create a new custom object with an existing label like Product, Task, Survey, etc.)

Working with your team

Let’s not forget about the all-important soft skills. It all starts with clear communication.

  • Do communicate well. Be clear and concise with email, face-to-face, Zoom, Slack, Teams – whatever your organization uses. Soft skills are critical. Listen and ask questions.
  • Do find internal Salesforce champions. These users exist in every Org. Do work closely with your power users.
  • Do help your Users with List Views by creating meaningful List Views and teaching users how to ‘clone’, add new fields, change the field order, filter, and share their personal view to co-workers.
  • Do configure Home Pages for Users. You can assign Home Pages by App/Profile, as needed.
  • Do suggest improving Lightning Record Pages by reviewing them with Business Users:
    • This is ‘low-hanging fruit,’ and are easy changes for an admin to make – often providing tremendous benefits.
  • Do provide effective Training materials such as written/electronic instructions, with simple to follow screengrabs. For mid to large changes, do provide live/Zoom training sessions, and make recordings available to Users. Store in public drive or on Salesforce (i.e. Salesforce Files).
  • Do suggest automation for Business Users, as appropriate:
    • Example #1: Help your Users by auto-populating certain fields, instead of having Users type in manually (i.e. auto-populating a ‘Sales Region’ field on the Opportunity record, based on the Opportunity Owner).
    • Example #2: Automate Email Alert ‘Notifications’ when key events happen (i.e. a change in Status to ‘Closed won’ or ‘In Jeopardy’)
  • Do create meaningful Reports & Dashboards for your end users and business stakeholders.
  • Don’t forget to document new processes and procedures and store them in a public drive or on Salesforce.
  • Don’t forget to prioritize your work.
  • Don’t just use audio for remote communications. Experts say communications are 80% non-verbal. A simple nod is priceless. So, if you’re using Zoom or a similar tool, video is helpful.
  • Don’t forget to ‘un-mute’ yourself. 😊 I’m guilty of this!

Staying Current with Salesforce

One thing is certain about Salesforce: the platform and related applications will continue to evolve at Lightning speed. With three major releases per year, keeping up is critical. It’s also fun!

  • Do use Trailhead. Salesforce Admins should use Trailhead to keep up with new functionality and broaden his or her skillset.
  • Do subscribe to – SalesforceBen has so much information to stay up-to-date on Salesforce features, news, and more.
  • Do register for TrailheaDX and Dreamforce.
  • Don’t forget to maintain your certifications before they expire. Ouch. This happens. Don’t let this be you.
  • Don’t ignore reviewing the new functionality in each Salesforce Release.


The Salesforce Admin holds the keys to the Salesforce org – and because of this, it is crucial the admin follows certain do’s and don’ts. Even Winston Churchill said in 1906, “Where there is great power, there is great responsibility.” Salesforce is the engine that can take your organization to the next level of customer/client experience – so steer the ship forward!

8 thoughts on “Salesforce Best Practices for Admins: Do’s and Don’ts

  1. As a new admin this information is invaluable. I have bookmarked this page so I can refer back to it as needed. Thanks.

  2. I noticed your comment about the system admin profile. What is your recommendation for the profile to use for developers in production?

Add Comment