Earlier in salesforce we used to have workflows and apex triggers to automate our business process leaving us with almost no chance but to opt in for a trigger in most of the complex cases, However with release of Process Builder and flows along with ability to invoke an apex method from process builder opened up a whole new world for salesforce developers/Admins to play around with. I would say it is a boon for salesforce admins who are struggling to write apex triggers.
This article mainly focuses on approaching the right design for your custom implementation when you have the requirement. I will have a stand alone blog just to focus on combination of process builder and flow along with reusability of flows.
Process Builder + Flows:
With Process Builder, you can:
- Create a record of any object type
- Update any related record—not just the record or its parent
- Use a quick action to create a record, update a record, or log a call
- Invoke a process from another process
- Launch a flow—you can’t schedule this action with workflow
- Send an email
- Post to Chatter
- Submit a record for approval
- Call an apex class
When calling a flow from process builder you can automate functionalities like syncing Account teams and opportunity teams or different child tables based on criteria utilizing the bulk elements like Fast update, Fast delete and Fast Create available in the flows.This approach best works when you can ignore the on delete criteria along with access to before DML and also when you don’t have to use complex data collections like List<List<Account>>, Map or Set in your logic. This requires no coding on your part and less maintenance and your initial criteria can be changed very easily.
Process Builder + Invocable Method
In the above scenario if for any reason we have to deal with complex data collections opt in for this combination. In this approach while working with complex data collections in apex you can still have the flexibility to change the initial criteria easily in the process builder. One of the limitation that carries over here is on delete scenario can’t be handled with process builder along with access to before DML.
Last but not the least approach. I’m not going much into details here as most of you are very much familiar with triggers. This should be the last option as trigger comes with maintenance along with lot of flexibility.If none of the above approach works for you just opt in for triggers and make sure you follow best practices while implementing triggers in your org, as power comes with lot of responsibility.