11 thoughts on “Just Say NO to Hard-Coded ID

  1. Thank you for the article. I see instances of hardcoding as well and it drives me nuts. One suggestion is that we always use DeveloperName to query for the queue or group as these are always unique (Nonprofit_Experts) while Name is not required to be unique.

    We don’t add a test for the existence of the queue as it must exist for our business processes. UAT will tell you if you forgot to deploy/create it or not. In your flow, you test for it and if it does not exist, do nothing. I would not recommend this. How do you know if something is wrong if your processes detect something missing but tells no one?

    What is valuable for the business I think is to test for membership to the queue. Is there at least one user where IsActive = TRUE? If not, instead of doing nothing, the negative branch would email the admin stating there is no one in this Queue.

    Thank you again for all you do. Automation Champion is a world class SF resource! Gerald Demers

  2. Rakesh Hi,
    As always, thank you very much for this useful information!

    As I can understand it, since IDs might change in different environments, it’s a best practice to use Custom Labels, Custom Settings or Custom Metadata Types.

    But, when using a Custom Label, for example, we DO add the ID (of a Queue, Record Type, etc.). So when I’ll create/deploy it in the Production Environment I might need to update it.

    So what is the advantage of using the Custom Label?

    Thank you in advance,

    1. Thank you so much for your feedback Gidi.

      If you don’t do this, then you have to deactivate your process, clone it, then update it with correct id.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.