Best Practices to Avoid Governor Limits
As a Salesforce Code Developer, you must follow some best practices to ensure that your code is scalable and does not exceed the governor limit. The following are such best practices:
- Bulkify your code.
- Avoid SOQL queries or DML statements inside For loops.
- Bulkify your helper methods.
- Use collections, streamlining queries, and efficient For loops.
- Streamline multiple triggers on the same object.
- Query large data sets.
- Use the limits of Apex methods to avoid exceeding governor limits.
- Use @future appropriately.
- Use batch Apex if you are working for more than 50000 records.
For more information, refer to Apex best Practices.
Best Practices for Customization
Best Practices for Customization
While implementing the following customization, you might encounter problems.
- Roll up Summary Fields: When you define Roll up summary fields on the Quotation object and clone a quote with line items, you may encounter issues like Apex CPU Time Out, because the calculation happens each time a new line item is created. Avoid defining Roll up summary fields if possible.
- Formula Fields: Because formula fields are calculated at runtime, they impact performance. For example, if you have 50 formula fields on a line item and there are 100 line items in the cart, 5000 formulas are calculated in a single SOQL. Use numeric expressions instead.
- SOQL: Any Query that takes 200 milliseconds or more is considered long-running. Optimize the query by requesting relevant fields and indexing fields in the where clause. Enable debug, keep database logs, keep the value of Apex Profiling to Finish in Debug Level Details, and turn off everything in log filter.
The following table lists the CPQ objects and the customization you can perform on those objects.
|
CPQ Objects |
Customization |
|---|---|
|
|
Follow the recommendations when you customize CPQ objects:
- Execute triggers on appropriate events, not on all events. For example, execute triggers before insert, after an update, and so on.
- Avoid defining a trigger on Line Item objects.
- Invoke any Apex record trigger, class, or extension for more than 200 records.
- Review any DML statements in a trigger, because these statements can trigger another set of triggers.
- Avoid using rollup summary fields if you have a trigger in place on the same object. Perform the required calculation in the trigger. If it cannot be avoided, the recommended maximum limit is 20.
- Avoid using more than 10 formula fields on one object, such as Line Item object and Proposal Line Item object, because it impacts CPQ performance. If you are creating a formula field on a line item only to access it in a Pricing Callback (PCB), you can use CPQ numeric expressions, so that you can avoid creating metadata fields. For more information, see CPQ for Administrators .
- Merge any workflow on a line item object into Pricing Callback if you have one.
- Ensure that the Product Attribute Value (PAV) fields are in sync on all PAV objects such as Proposal PAV, Asset PAV, Agreement PAV, and Order PAV.
- Consider creating skinny tables because they speed up the execution of SOQL queries.
- Avoid calling managed methods or APIs in a loop.
- Limit customization to the objects mentioned.
- Do not interpret the functional purpose of any standard field based on the value stored. When in doubt, file a support case for clarification.
- Creating triggers on common objects such as task, attachment, and so on should have checks to bypass in case of parent objects not relevant to that function. Check for this in preexisting code written before Conga is implemented.
- Only use Option Filter Callback when needed. Measure code and optimize custom code performance.
- Avoid using Process Builder and workflows on CPQ objects.
-
Avoid the combination of Process Builder, workflows, and trigger within the same object. Instead, move the logic from Process builder and workflows to triggers. You must not define more than five triggers on one object.
