Salesforce Best Practices: 20+ Feature Quirks You Should Know About

Whether you’re a seasoned Salesforce professional or a relative newbie, you’re likely to come across some quirks in the system. These quirks can be a blip in your day or they can leave you confused for weeks on end. 

Working together, Andreea and I made a list to note whenever we came across these interesting nuggets of knowledge – and now, we’re happy to share these with you so that you can be the best possible builder on Salesforce. 

Note: In this guide, we’ll be covering general tips. If you’re a marketer working with the Salesforce platform, also check out the Marketing quirks guide below:

1. Page Layout Changes 

When adding, removing, or moving fields on page layouts, you may find that the changes take some time to be reflected on record changes. This time lag will vary from org to org, so be patient when working with page layouts, or just log out and in again!

2. New Field Not Appearing in Lightning

As a best practice, metadata changes, including page layout updates, should be done in a sandbox prior to being deployed to production. While checking out the changes, you might notice that they sometimes take a long time to appear in Lightning but they appear as intended in Classic. 

According to the documentation, disabling the secure and persistent browser caching used to improve performance in a sandbox or Developer Edition is recommended in order to see the code changes without emptying the secure cache. However, disabling it also works just as well for layout changes to quickly appear when logging out and back in doesn’t do the trick. 

Keep in mind that disabling this setting in Session Settings will have a negative performance impact on Lightning Experience, so unless you’re using it is against company policy, only do this if needed in a sandbox.

3. Lightning App Builder: Custom Tabs

When clicking “Edit Page” to launch the Lightning App Builder, adding tabs is simple – however, there are a couple of quirky things going on. 

The first is custom tabs. When adding a new tab, it will default to “Details”. If you want to use a custom tab name, you need to scroll to the top of the expanded list. Being sorted alphabetically, and depending on the number of objects and apps installed in your org, “D” might be quite far down the list! 

4. Lightning App Builder: Disappearing Tabs

Following on from the previous point, if you add tabs to a tabs component, even after saving/activating the page, they can still disappear. Any tabs need to have components added within them to be “sticky”. In the example below, the Pipelaunch tab has the Company Insights component added to it, which means that the Pipelaunch tab won’t disappear when you exit the Lightning App Builder “Edit Page” view.  

5. Lightning Page Filters

Similar to how field access is needed for Report filters, the same principle applies to Record Page or Home Page Component filters. This means that in the situation below, if the Rich Text Component filter uses the Rating field on the Account, access is needed for that field for it to correctly appear (or not) to the users. 

If you have noticed a similar behavior with the component not appearing, it’s definitely worth taking a look at the field permissions. 

6. Searching for Records in Reports

Building and running Reports in Salesforce is something users and admins do almost every day. While it may be a well-known fact that the results are limited to two thousand rows of data to be visible on the run page itself, have you ever fallen into the CTRL + F trap? 

Using the good old CTRL + F / command + F mechanism to search for a certain record in a Salesforce report can be ‘hit or miss’ and may not catch all occurrences – check out the “pyramid” example below. This may not be the best news, but the built-in search works as intended; it’s a matter of enablement to ensure how the search is done. Of course, another alternative is to use Report filters, but that would mean editing the report multiple times. 

7. Sharing Report/Dashboard Folders

This one caused some confusion between our admins and our users. Having granted folder access to our “All Internal Users” public group, some people were unable to access the reports/dashboards stored within that folder. Upon revisiting the folder’s sharing settings, the public group had disappeared. 

No, this was not a case of Salesforce reverting the share settings – in fact, it turned out that the settings were never set in the first place! When adding users or groups, you need to click the “Share” button for them to be added to the list below. With the button colors dictated by the Salesforce UI, this button can be easy to gloss over. The more prominent “Done” button is misleading, so you need to click both buttons to avoid this mysterious case of sharing settings. 

8. Full ID Formula Field vs. Report Column

In a Salesforce record’s URL, you will see the 15-digit ID. For integrations and imports, using the 18-digit ID is preferable. It’s a common practice to create a formula field on the object to surface the 18-digit ID, like this: 

However, did you know that you can also do this in a report? If you already created a formula field, you can add the column Full ID as a report column. However, if you also already have a custom field (not lookup) with a 15-character ID, you don’t necessarily have to create yet another field for the 18-character one – you could use the CASESAFEID(Custom_Id_field__c) directly as a row-level report formula. This is, however, a very specific scenario, applicable in the situation in which you created a separate field to store an ID for a different reason. 

9. 18-Digit ID for Record Type Isn’t Web-to-Lead Friendly

Web-to-Lead may still be used by organizations and has been around for a long time as a mechanism to automatically create Salesforce Leads from the website. While hard coding IDs is a big no-no, you may attempt doing this for the purpose of using this functionality when it comes to defining the Lead Record Type on different forms.

Surprisingly, in this situation, only the 15-character Record Type ID does the trick. Although using the 18-character one will not prevent the Lead from being created, it will just not work. 

Before choosing to use Web-to-Lead, be sure to check the other considerations as well, and while optional, don’t forget to use reCAPTCHA! 

10. Lead Currency + Conversion

The Currency field may seem quite strange as it is, considering it comes as a standard field on every new custom object. On the Lead, however, it makes sense to have it in the eventuality that a new Opportunity is created through Lead conversion. Since the Opportunity will have an Amount sooner rather than later, it would be best for the currency to be right from the get-go. What happens though when converting Leads to existing Opportunities? 

This Currency quirk also produces a ‘nice’ error for the users which doesn’t explicitly refer to any field in particular. This means that rather than encountering it, it’s best to prevent it either through automation or enablement. The Lead Currency has to match the one from the existing Opportunity. 

11. Edit Currency Fields

Since we are on the topic of currency, we all know how crucial it is for fields containing amounts and revenue to always be up to date. This means that the more accessible and user-friendly the editing process is, the better. A bit of a quirky detail appears when editing in-line in a Salesforce Report – despite it being a time-saver, it may raise a currency discrepancy question. 

As you can see in the example below, even though multi-currency is enabled in an organization, and the record currency is other than USD, the “$” symbol still appears while edits are made. 

However, once the changes are saved, the correct currency is also displayed in the currency field as usual. 

While the dollar sign quirk might raise questions in case it’s noticed, there is another currency edit that may make users happy considering they will save a few keystrokes when entering numbers in currency fields on the layout, not in the Report. 

Looking at the same annual revenue example, entering a number followed by the letter of the desired unit abbreviation: typing 5K, 50M (million), 5B (billion), or even 5T (trillion) on the keyboard will result in Salesforce simply adding the afferent number of zeros, so you don’t have to.

12. Changing Person Account to Contact (And Vice Versa)

In both of these scenarios, with a few different considerations, the changes will have to be done through API, especially if it’s a one-time change. Data Loader, for example, would be an easy way, as long as no other field updates are done at the same time.

For a Person Account being changed to a Business Account, importing a CSV file with the Account ID and Record Type ID (one of the Business Account ones) will do the trick. For a Business Account being changed to a Person Account, you also have to ensure that at least one Contact exists, then use the Record Type ID for the Person Account instead for the import. 

If this is not a one-time situation, automations can also be explored based on your requirement to reduce some manual work, for example by leveraging Salesforce Flow. 

13. Field Order in Flow Assignment Element

Working with variables in Salesforce Flows is perhaps one of the most powerful functionalities in this automation tool, and setting values for these variables implies making use of the Assignment element. Everything is quite straightforward until you have to make changes/additions to the value assignment and perhaps encounter the quirk where there’s no option to re-order the items within the Assignment element. 

For example, if you are assigning a single variable to a collection variable as the last item, you will have to remove this and add it back once additional fields are added. 

There already is an open idea for this which you can vote for, with the hope that reordering within the Assignment element will become a possibility in the future. 

14. Global Picklist Values Selection and Order

Global picklists are a set of consistent values that can be applied to picklist fields across any object in your org, therefore, helping to keep your values consistent. 

You may know that when using record types, you can select which picklist value and the order they are presented in, per record type. For example, you may have a “closed lost” global picklist that you wish to use on leads and opportunities. Say you have two opportunity record types, you can select different values/order of values for “New business” vs. “Renewals”. 

However, what we discovered recently is that when using global picklists on objects where there are no record types, you cannot change the value selection/order of values. Continuing our example above, the picklist on leads would appear as how the global picklist has been set up.

15. Copying Picklist Values (Printable View)

Speaking from our personal experience, the first discovery of the printable view is a revelation for people. 

You may find it easier to work in a spreadsheet when planning for, or tidying up, picklist values. Copying the table of picklist values and pasting it into a sheet/document will bring in all the columns (and will look messy!).

By using printable view, generate a clean list of values in a pop-up window that will save you unnecessary formatting work. 

16. Setting Field Accessibility on Permission Sets

As it’s still a relatively new feature, the possibility to enable Field-Level Security for Permission Sets during Field Creation in User Management Settings is a step up in managing the permission set updates directly from the Field Level Security button from individual fields, either when the field is created or as an update afterward. This removes the multiple clicks previously involved in adding read/write permissions for each field in multiple Permission Sets. 

What you may initially miss, especially when using this for the very first time, is the automatically selected box that displays only Permission Sets which also have Object permissions. Only by unchecking it will all the other Permission Sets also become available to add read or write permissions to. 

17. Tab Visibility by Profile

When creating object tabs, the “Add to profiles” (step 2) page presents a list of all profiles in your org, with Default On applied to all of them. What if, for example, you want Default On applied to only one profile? Do you sit there and change all the others to Default Off or Tab Hidden? 

What if there was an easier way? Using the radio button “Apply one tab visibility to all profiles” changes this to the visibility setting you want the majority of profiles to use. Then you can switch back to “Apply a different tab visibility for each profile” where you will be able to change the one profile to Default On – a nice time-saving hack. 

18. Login Using Custom Domain

Company-owned Salesforce orgs will use a custom domain for a number of reasons, in the format https://[your company].my.salesforce.com/.

All pages in your Salesforce org will start with this URL, including your login page. 

It’s common for users to Google “Salesforce login”, land on a generic login.salesforce page, and wonder why they can’t log in using their credentials. 

Encourage your users to bookmark the login page/home screen on their browser so they’re always directed to the right place.

19. Phone Number Formatting

When it comes to the standard Phone fields, there are a few things to consider about formatting, but the quirk here is definitely the automatic formatting based on User Locale. If the locale is set to English (United States) or English (Canada) the following behaviors will occur: 

• If the phone number has 9 digits only, the number will be saved as such without any formatting.
• If the phone number has 10 digits, a number such as 1234567890 will be formatted as (123) 456-7890.
• If the phone number has 11 digits and:
  • Starts with 1, then the 1 will be removed while the others will be formatted with a parentheses and hyphen. 
  • Starts with any other number than 1, then no formatting will be applied and the 11-digit number will be displayed as such. 

You can however opt to apply custom formatting by introducing a “+” before the number. Also, consider the 10 digit Lightning vs. Classic formatting behavior in case your organization hasn’t fully migrated to Lightning yet. 

20. END Element Not Searchable in Flow

If you are working with Salesforce Flows (hopefully you are considering the goodbye to Process Builder and Workflow Rules), this one may have caught your attention. The End element was introduced a while back, and it’s helpful when it comes to stopping the flow, especially after a decision element if one of the outcomes results in the flow stopping. 

While a click and a search generally helps you select the element you need, the End element is not searchable like the others. This means that you will have to scroll through the list and select it, however tempted you may be to just type “end”. 

21. Change Owner List View Button Leads

There are situations in which your users would like to be able to transfer the ownership of multiple Leads from a List View. While they might already have edit permissions on the Lead Object, they will still not see the Change Owner button even if it is on the List View Layout.

An extra permission is needed in this situation, be it the dedicated Transfer Leads or the Transfer Record (this one will apply to other objects too, so weigh in the requirement before deciding!). Note that while Transfer Leads can be found under App Permissions to be added to the Permission Set, Transfer Record is under System Permissions. 

22. Required Field Permissions

The “Required” option at field level may not be as widely used as other ways such as Validation Rules or even the newer Flow Custom Error component to ensure a certain field is completed, but when making use of it, there is one quirk to be aware of: the permissions for it. 

When deploying the newly created required field, make sure that it is not referenced in any Profile or Permission Set metadata like you would do with any other field to quickly add the permissions in the XML file. This will cause your deployment to throw an error pointing to the reference. If you check in the sandbox the field was created in, you will notice that the permissions are automatically added on all Profiles and/or Permission Sets, and you can’t edit them. 

Summary

Although they can be quite a headache, especially when encountering one for the very first time, Salesforce quirks remain something to keep in mind while working with the platform. We have covered a few general ones in this post, but surely there are a few more out there left to discover. 

Have you encountered any of the ones from the list? What about others? Let us know in the comments below!