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?
- 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!
- 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!
- It is easy to lose context for what that hardcoded ID.
- 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!
- 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:
- Group (Filter by Type)
- Public Groups
- Chatter Groups
- RecordType (Filter by Object)
Tricks of the trade:
- Query using the DeveloperName when possible. This allows you to change the Label without breaking anything.
- 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!