Salesforce Sidekick

We all know this, but we don’t all do this.  Please, don’t hardcode IDs!  I will start this off by admitting I have done this many times, and still do it occasionally.  However, whenever I do it now – I have to be able to justify it.  If you can avoid hardcoding an ID – do it!
What are the disadvantages for hardcoding an ID?

1. If you are developing in the Sandbox, the IDs of newly created Record Types, Permission Sets, Public Groups, Accounts, Contacts, or anything else will change when you get to Production!
2. You might miss something when you change the IDs from Sandbox to Production and your Flow won’t be fully functional.  Your testing has to be done all over again!
3. It is easy to lose context for what that hardcoded ID.
4. The System uses 18 Digit IDs when you assign an ID to a variable (referring to Flow).  If you paste in the 15 Digit ID you run the possibility of issues with EQUALS operators… beware!
5. Did I mention IDs can change?!  Don’t do it!

When you think about if you could just hardcode an ID rather than doing that extra query, just remember this:

Top Objects to Query:

1. Group (Filter by Type)
   • Public Groups
   • Queues
   • Chatter Groups
2. PermissionSet
3. RecordType (Filter by Object)

Tricks of the trade:

1. Query using the DeveloperName when possible.  This allows you to change the Label without breaking anything.
2. Use Custom Settings or Custom Metadata Types!  Fun fact, Custom Settings don’t count against your SOQL Limits.  I will admit, I was a late adopter but love them now!