Salesforce Development: 5 Common Mistakes and How to Fix Them
Salesforce development and customization requires a sound knowledge of Force.com. Visualforce is a framework that allows developers to build sophisticated, custom user interfaces that can be hosted natively on the Force.com platform. Apex is the native programming language of Force.com that lets you execute flow and transaction control statements. But unlike usual coding platform, Salesforce imposes limits due to its multi-tenant cloud structure. Below are 5 mistakes a Salesforce Development team should avoid while customizing on Force.com
1. Reaching SOQL queries limit
As a multi-tenant vendor, you can’t allow a customer on a CRM instance make millions of API calls per a minute. Because this can affect the performance for other customers on the same instance. Thus, Salesforce has kept governor limits which restrict the no. of API calls over a period, which prevents writing bad code and eating up of cloud processing space. One such governor limit is imposed on Salesforce Object Query Language (SOQL). The total number of SOQL queries issued are 100 in synchronous limit and 200 in the asynchronous limit. It is advisable to follow proper guidelines while using Apex code, such as avoiding queries inside FOR loops, using Apex collections, writing exhaustive test cases etc.
2. Multiple Triggers on the same object
Apex triggers enable you to perform custom actions before or after events to records in Salesforce, such as insertions, updates, or deletions. But for a particular scenario (such as ‘before insert’) it is advisable to write single trigger. Writing multiple triggers renders the system unable to recognize the order of execution. Moreover, each trigger that is invoked does not get its own governor limits. Instead, all code that is processed, including the additional triggers, share those available resources.
3. Not Bulkifying your code
Bulkifying your code refers to combining repetitive tasks in Salesforce Apex such that the code properly handles more than one record at a time. Neglecting bulk code leads to hitting governor limits. When a batch of records initiates Apex, a single instance of that Apex code is executed, but it needs to handle all of the records in that given batch. For example, a trigger could be invoked by a Force.com SOAP API call that inserted a batch of records. So if a batch of records invokes the same Apex code, all of those records need to be processed as a bulk, in order to write scalable code and avoid hitting governor limits.
4. Troublesome User Experience
Visualforce allows you to develop a rich UI with pop-ups and images, but can be troublesome for the user. Pages overloaded with data and functionality makes clicking or navigating to buttons difficult. Design in Visualforce should be around specific tasks with defined workflow and navigation between tasks. Also unbound data or a large number of components affect performance and risk hitting governor limits for view state, record limits, heap size and total page size.
5. Keeping Hardcoded programs
While Salesforce development works on improving the formula and keep the Apex code dynamic. Keeping hardcoded URLs can be disastrous if the environment gets changed. Thus, the concept of dynamic URLs is beneficial in the long run.
