After spending some time on different Salesforce projects, I came along a few practices that, sometimes can feel like a good idea, but really aren’t. Or some that are, in my opinion, definitely and undeniably wrong. Today I will share some of my favorite ones with you.
Sharing a Salesforce License
- It actually violates Salesforce’s terms of service (and that should be enough)
- How can you know who does what in your org?
- Good luck dealing with passwords and Two Factor Authentication…
Each user should and must have its own licence.
No proper Naming Convention
Defining a Naming Convention is among the first steps of a project. For Admins as well as Developers (and maybe even more for Admins), it’s key in understanding, productivity, and just basically in avoiding chaos.
If somehow you still have doubts, here is a great article on the topic.
Having Labels and API Names that don’t match
Another Salesforce bad practices is having labels and API names that don’t match. What could be so bad? It’s mainly only on the layout, isn’t it? Well, try arriving on a project with several dozen custom objects, with numerous fields and custom developments.
- Client, admins and developers won’t speak the same language.
- It will definitely make developers’ job harder.
- You might end up with some duplicate labels on the same object without even realizing.
Instead of modifying the label, I’d recommend using custom labels.
I know most people don’t think about this, but in my opinion it’s strongly linked to the precedent topic and as important.
Too many fields per object
This one is the trickiest one when it comes to helping your client understand its impact. But in the end, it really comes down to this question : Who are you building your application for? You want user adoption as well as pertinent and powerful metrics. All I can say is a Sales Representative will neither have the time nor the patience to fill 40+ fields each time he has to create a new Account or Opportunity… And let’s not talk about what it would do to its productivity!
Also, it can be a sign of poor architecture… You should really think before adding a set of fields to an object if it really belongs there.
Multiplying Sharing Rules
Clients just love sharing rules. They allow for so much flexibility when it comes to who sees what. But…
- They are SO expensive in terms of performance. Just imagine. Each time a user will search for records, consult list views reports or dashboards all these sharing rules will have to be calculated in addition to all others sharing features. Once, I had a population of Sales Representatives that wasn’t able to open a report. They got a time out error!
- Good luck debugging record access errors…
This is why upstream reflexion is really key in designing sharing and access to records.
Alternatively, this may be a sign that too many populations of users, with too many different business processes are reunited in the same Salesforce organization…
Too many Processes per Object
Process Builders are often treated as a better version of workflow rules. So, a common misconception is that you can and should multiply processes the same you do with workflows.
But you should consider Process Builders the same way as Triggers: one per object.
- Process Builders have very robust features to support that assumption.
- With multiple processes, how do you know which will fire first?
- It will immensely simplify your debugging actions.
These are our Salesforce bad practices. Now if you want to learn more about Salesforce, take a look at our article Lightning Migration for Admins : the opportunity to clean and improve your Org to meet flexibility
