{"id":490,"date":"2020-02-11T08:31:01","date_gmt":"2020-02-11T07:31:01","guid":{"rendered":"https:\/\/transferttexei.wordpress.com\/2020\/02\/11\/data-manipulation-in-salesforce-pragmatic-tips-for-daily-use\/"},"modified":"2023-08-18T14:45:09","modified_gmt":"2023-08-18T12:45:09","slug":"data-manipulation-in-salesforce-pragmatic-tips-for-daily-use","status":"publish","type":"post","link":"https:\/\/texei.com\/en\/advices\/data-manipulation-in-salesforce-pragmatic-tips-for-daily-use\/","title":{"rendered":"Data manipulation in Salesforce\u00a0: pragmatic tips for daily use"},"content":{"rendered":"

When it comes to managing your data in Salesforce, there is a lot of content everywhere. How to design your data model<\/strong>, how to assess and manage<\/strong> your data quality,<\/strong> how to turn your data into powerful reports and dashboards<\/strong>, how to leverage ETL tools<\/strong>\u2026 And so on. Today, I want to focus on how to simplify data manipulation on a daily basis<\/strong>.<\/p>\n

Why? Because Salesforce consultants, administrators and sometimes key users manipulate sets of records everyday<\/strong>.<\/p>\n

And let\u2019s be honest, even with the best team organization, ETL tool and processes\u200a\u2014\u200awhich are never a given\u200a\u2014\u200awhether you are a young Padawan or a Salesforce Jedi, we have all made a mistake one day or forgotten fundamental rules in our haste. And rolling-back can be very hard\u2026<\/p>\n

So, here is a list of basic tips<\/strong> that I find are essential when manipulating data in Salesforce on a daily basis<\/strong>. Yes, sure, some of you will tell me that most of it is just common sense. But it never hurts to repeat them, does-it?<\/p>\n

Data manipulation: structural tips<\/strong><\/h3>\n

Simplify your life with custom activation<\/h4>\n

Anytime, for any reason and any user, you want to be able to bypass the rules and processes<\/strong> in place. For example, you have to update opportunities but you don\u2019t want to enforce Validation Rules and you don\u2019t want the Triggers nor the Process Builders to run.<\/p>\n

Well, there are several ways you can use to gain flexibility <\/strong>but I definitely recommend using Custom Permissions<\/strong> as a best practice.<\/p>\n

    \n
  1. They can be assigned via a Profile or a Permission Set<\/li>\n
  2. They can be referenced in Validation Rules, Workflow Rules, Process Builders, Flows, Apex Code.<\/li>\n
  3. Contrary to Hierarchy Custom Settings they are metadata and not data. \u201cSo what?\u201d, will you ask. Well, it means that Custom Permissions will be easier to manage in unit tests<\/strong>. Custom Settings need to be populated in your tests whereas Custom Permissions don\u2019t. This is why Custom Settings are only, in my opinion, second best option.<\/li>\n<\/ol>\n

    Let\u2019s see an example with Validation Rules.<\/p>\n

    \"Data
    Example\u00a0: Create a Custom Permission to Bypass Validation Rules<\/figcaption><\/figure>\n
    \"\"
    Example\u00a0: Use a Custom Permission in a Validation Rule<\/figcaption><\/figure>\n

    Now, don\u2019t forget to assign your Custom Permission<\/strong> to a profile or a Permission Set and all the users with this profile or permission set will ignore this Validation Rule.<\/p>\n

    Another quick example, with Process Builder.<\/p>\n

    \"\"
    Example\u00a0: Use a Custom Permission in a Process Builder\u00a0Criteria<\/figcaption><\/figure>\n

    Note\u00a0: you\u2019ll find your custom permissions in the formula editor by clicking on the third lookup\u00a0: System Variable.<\/p>\n

    Depending on your needs, you can even choose a finer granularity, at Object scale and define permissions such as BypassAccountTrigger or BypassOpportunityWorkflowRules for example.<\/p>\n

    Still need more convincing? You can read the article of my co-worker Mathieu Demuynck<\/a> on the subject here<\/a>.<\/p>\n

    Use External\u00a0Ids<\/h4>\n

    Yes, please. They are essential for data integration or migration.<\/p>\n

      \n
    1. They help you prevent duplicate records<\/strong> from being created<\/li>\n
    2. Of course they help identifying records with external systems<\/strong>, but also simplify<\/strong> populating and maintaining data in your sandboxes<\/strong>.<\/li>\n
    3. They are great when you need to import related records.<\/li>\n<\/ol>\n

      Define and enforce a naming convention<\/h4>\n

      Naming conventions should be defined as early a possible<\/strong> in a project and followed 100% of the time<\/strong>. They involve all metadata<\/strong> (Apex classes, Workflow Rules, Validation Rules\u2026) and data<\/strong> (record naming).<\/p>\n

      Beyond representing a real gain in productivity<\/strong> for everyone, they\u2019re also key to preventing, among others, fields and records duplication, coding and reporting problems.<\/p>\n

      Here are two articles on the subject\u00a0:<\/p>\n