{"id":487,"date":"2021-04-23T09:19:45","date_gmt":"2021-04-23T07:19:45","guid":{"rendered":"https:\/\/transferttexei.wordpress.com\/2021\/04\/23\/salesforce-my-favorite-bad-practices\/"},"modified":"2023-08-18T13:57:31","modified_gmt":"2023-08-18T11:57:31","slug":"salesforce-my-favorite-bad-practices","status":"publish","type":"post","link":"https:\/\/texei.com\/en\/advices\/salesforce-my-favorite-bad-practices\/","title":{"rendered":"Salesforce\u00a0: my favorite bad practices"},"content":{"rendered":"

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\u2019t. Or some that are, in my opinion, definitely and undeniably wrong. Today I will share some of my favorite ones with you.<\/p>\n

\"\"<\/figure>\n

Sharing a Salesforce License<\/h2>\n
    \n
  1. It actually violates<\/strong> Salesforce\u2019s terms of service (and that should be enough)<\/li>\n
  2. How can you know who does what in your org?<\/li>\n
  3. Good luck dealing with passwords and Two Factor Authentication\u2026<\/li>\n<\/ol>\n

    Each user should and must<\/strong> have its own licence.<\/p>\n

    No proper Naming Convention<\/h2>\n

    Defining a Naming Convention is among the first steps of a project<\/strong>. For Admins as well as Developers (and maybe even more for Admins), <\/strong>it\u2019s key in understanding, productivity, and just basically in avoiding chaos<\/strong>.<\/p>\n

    \"\"<\/figure>\n

    If somehow you still have doubts, here<\/a> is a great article on the topic.<\/p>\n

    Having Labels and API Names that don\u2019t\u00a0match<\/h2>\n

    Another Salesforce bad practices is having labels and API names that don’t match. What could be so bad? It\u2019s mainly only on the layout, isn\u2019t it? Well, try arriving on a project with several dozen custom objects, with numerous fields and custom developments.<\/p>\n