Best Practices and Recommendations for New Salesforce Admins (Part One - Setup Best Practices)

They say hindsight is a wonderful thing and they are right, we can't go back and do over, but we can share what we have learnt and allow others to benefit from our experiences.

This was my approach to the session I presented at the Admin Theatre at this year's London World Tour. My talk was entitled Best Practices and Recommendations for New Salesforce Admins.

The role of Salesforce Admin brings with it a lot of responsibility, but thankfully also all the tools and support to enable each of us to be successful. When we start our Salesforce journey, however, we don't come with all this knowledge fully formed so here are my recommendations and tools to help everyone make the most of the available (#Safe Harbor) features.

For ease I am splitting my tips up into Best Practices, Recommendations, and Tools, and then into Setup, Reporting, and Productivity.

This post (part one) covers Setup Best Practices.

Number one in my list of setup best practices relates to the provisioning of permissions to your users. When it comes to giving out access to your users it may seem easier in the short term to be very generous with the permissions you allocate. You might even wonder what the harm is in making everyone an Admin (essentially by giving them the 'Modify all Data' and 'View all Data' permissions) but don’t. 

The price of not ever hearing about an insufficient access error is not worth the loss of control, audit tracking, and integrity.

This is where Permission Sets are an Administrator’s friend. I recommend you build out a baseline profile with only the fields and permissions that every user of that type needs and then use Permission Sets to add specific permissions and field access to specific users.

You may end up with a lot of Permission Sets (for each department, division, or requirement) but the building block permission approach will enable tailored access and control. Name your Permission Sets clearly, giving them a description detailing which permissions and object/field access is included and you will make user management easier for yourself, and your successors. 

This isn’t just about control, but usability. As an Admin we typically end up with the worst page layouts possible as we have FLS for all fields, making our screens long and cluttered. I don’t want that same experience for my users, who may think they want to see everything, but a neat page with only the fields critical to their role is what they really want and need.

One of the things I always say about Salesforce is that it provides great visibility and track-ability, and a lot of that is through the history tracking functionality available on each object. However, a new org doesn't come with this working from day one, it requires activation and setup. This makes it something that all new admins should be aware of.
It is very easy to do and if you aren't sure whether you have it enabled and configured, I recommend you login now and check.

Navigate to the object in Setup - click Set History Tracking under Fields & Relationships - tick Enable (for standard objects) - Select the fields you would like to track. Hit Save. (See screen shots above).

It is available for both standard and custom objects so take a moment and make sure you are tracking the right fields.

Once you have this setup and it starts collecting data then you can write reports on the results. This makes it invaluable to keep a track of what your users, or your integrations, are changing.

Tips - Don't forget to add the object's History related list to your page layouts.

          There is a limit of 20 fields which can be tracked per object so choose wisely.

          Tracking starts at point of activation, it is not retrospective.

If I had to name one piece of functionality I wish I had available to me from day one, then this feature would be challenging for the top spot.
If you haven’t already, please go and check it out. It is not something you can just turn on without consideration and testing but it is well worth the time upfront. You have to configure your matching rules and then your duplication rules but my advice is to start with something simple.

I started by putting a block on a contact being created with an email address which was already in the system. Email is quite a common unique identifier and duplicates are often added as people mistype a name, or search for Robert instead of Bob (for example). Duplicate email addresses cause problems for integrations with email providers as well as other systems and general usability.
Duplicates are the enemy if you are trying to establish a single view of a customer.

Setting up duplication management was a great step forward for my data standards. I didn’t just apply the 'warn' feature though, I blocked the creation of a contact with a pre-existing email address (see screen shot above).

Be aware though, you will need to consider whether any processes or integrations create records in your org and decide whether to exclude them from the rules.
Also please consider your matching logic carefully. Matching Accounts by postcode may seem straightforward but many businesses share postcodes. Also if your users get used to ignoring the warnings then the rules quickly serve no purpose.

To learn more please refer to the documentation here - https://help.salesforce.com/articleView?id=managing_duplicates_overview.htm

There is also a Trailhead Module for this feature which is included in my Trailmix here bit.ly/LLAdmin

I'm confident that your users use Salesforce’s search functionality every day.
That said, not everyone will know that there are ways that we can tailor the search screens to make them even more useful.
As Admins we are able to configure which fields are displayed on the search page and which filters are available.
Navigate to the object(s) in question and click Search Layouts, there you can choose which fields appear on the search page, and which fields can be filtered on. In Classic this also applies to Lookups.
While we wait for filtering on related lists Search Filters remains the best way to filter your data on the fly.

As your org matures, the number of fields and processes you have will grow. The name you give a field today might make perfect sense but try remembering it in several years time. Give each new field a description and use the help text to steer your users in how to complete the field. If the field is updated by, or feeds into a process then make sure you add a reference to that, your later self will thank you for it.

That's it for part one.

Part Two -  Reporting Recommendations is here.
Part Three - Productivity Recommendations is here.
Part Four - Tools is here.

The Trailmix I created alongside this talk and blog series is here.