Trigger + Process + Workflow = Recursion Hell?

As your Salesforce org matures, chances are you'll find yourself trying to untangle Apex triggers, processes created with Process Builder, and workflow rules. Specifically when field updates are involved, predicting the outcome from the order of operations can be a pita, especially because the documentation still leaves room for questions in cases involving recursion.

Follow the two rules below for a reduced-pain implementation.

• One trigger per object
• No autolaunched flows. Use Process Builder, but avoid invoking autolaunched flows. If you've already got a trigger involved, whatever you need to do in an autolaunched flow can be handled in Apex, with the added benefit of Apex tests to cover yourself.

If you're updating fields on a in Process Builder, and you've marked the "Recursion" checkbox, know that every time the record is updated by the process, before and after trigger events will fire again. This is also true for updates made by a process invoked as an action by another process.

So all in all, remember that a single Apex trigger could run 14 (fourteen) times for a single DML operation! If you're mixing triggers with processes and workflow rules, make very sure your business logic in triggers will survive recursion.

getValue() getter method vs. { get; } shorthand

Salesforce's { get; set; } syntax has been around for a long time and is a time-tested, reliable way to define properties in Apex. But after testing its usability and limitations in Spring '17,  I've decided that explicitly declaring traditional getter and setter methods should be preferred over using the convenient { get; set; } syntax.

The primary reason is that the only way to expose a property in a custom Apex class for use with Lightning Components is to use the @AuraEnabled annotation, and this annotation only works on a traditional getter method such as String getName().

The secondary reason is that the developer also has the option to either call the getter or access the private field directly from other methods in the class, which is not possible when using { get; set; }.