![]() ![]() When we begin writing a brand-new class, one of the first things we should do is declare our sharing model. However, just because it is static now doesn’t mean it always will be, and so we should probably also store it in custom metadata (if required), just to be on the safe side. This is the special default record type and is fixed across all instances. There is only one scenario where we don’t need to follow one of the two above approaches, and that is where we are explicitly referencing the Master Record Type. If the ID we wish to use relates to a specific record, we can instead store this ID into custom metadata and retrieve the value at runtime, allowing us to freely change the value between environments, or as requirements change. If we wish to utilize record types, instead we can reference them via their DeveloperName which will be consistent across environments. Consider the opposite situation: if we create a sandbox from production, our hard-coded IDs will no longer point to the correct records. This is especially true for Record Types created in a sandbox and then migrated into production. Hardcoding IDs might work fine and without incident when they are developed, but as soon as we migrate our code into production, those IDs will no longer reference the correct record. ![]() You may consider hard coding this variable, but that would be a bad idea! ![]() For almost all situations, this is the safest and best approach.īoth of the above techniques not only improve our performance and help safeguard against governor limits, but also help improve the readability and maintainability of our code by allowing us to more easily modify it and add new functionality (if required).Ĭonsider the scenario: you need to always set the Account lookup on a specific record type of Contact to be a specific account. So, sticking them into a loop is a recipe for disaster, as we can quickly and unknowingly reach these limits, especially when triggers are involved!įor DML statements, we can shift those statements outside of the loop and instead, within our loop, we can add the records we wish to perform those operations on into a list and perform the DML statement on our list instead. SOQL and DML are some of the most expensive operations we can perform within Salesforce Apex, and both have strict governor limits associated with them. You may be tempted to either query or run the DML on these records while within your for loop, because what’s the worst that can happen? Well, quite a lot… There are times when you may wish to insert/update multiple records at once, or query sets of records based on specific contexts. However, due to the ease of bulkifying most code, you should probably get into a good habit of doing it regardless! The only time you may choose not to bulkify your code is when you can guarantee the number of records in an invocation will be low – this may be from an API or an Apex action invoke via a screen flow. Consider use of maps can greatly reduce the complexity and the amount of time it takes your code to run by reducing the overall lines of code to be executed when compared to iterating over lists. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |