This post contains details on how Salesforce lightning process builder can be utilized where earlier you will use workflow rules or triggers. With process builder overlapping workflow functionality and many more features question arise when to use trigger, workflow rule or process builder. Lightning process builder which can be considered as successor of workflow rules allows more config options and reduces amount of apex customization required. As process builder already supports features provided by workflow rules (Except outbound messages) I will not be surprised if Salesforce decides to deprecate workflow rules in near future. Anyone building new workflow rules or triggers should definitely evaluate features of process builder.
Earlier workflow rules were not able to perform certain logic which required customization. Salesforce Triggers can perform activities like:
- Perform complex validations.
- before/after logic on update/insert/delete/undelete operations.
- update/retrieve/insert any object or related records
There are situations where you can utilize process builder instead of writing apex triggers. One of the common reason to write an apex trigger is to update children of an object. Salesforce Workflow rules can perform an update on parent record but not to child records. workflow rules also doesn’t support few standard to standard cross object field update. For example when case is updated then changing field on account via workflow rules is not possible. Many such limitations made it mandatory to write an apex trigger where you first retrieve related objects fields using SOQL and then update related objects. You can update all related objects using process builder without writing single apex code.
For example when job position status changes to ‘Open – Approved’ all related applications status changes to ‘Review Resume’. If you have to perform this operation in process builder then it looks like following:
In an above example Job Application has lookup to position object. in order to select fields of ‘Job Application’ object you will select its relationship name job_applications__r for update. Then you can select related object’s fields for update.
You can also utilize process builder to perform different group of actions filtered by conditions which can be executed when criteria are met. For example when job position is updated with ‘visa required’ flag checked all applications with flag ‘Is Visa Available’ as checked will be updated to status ‘Review Resume’ and other applications will get status ‘Rejected’. Both group of actions can execute and update the related records after process criteria have satisfied and records meet filtered condition for actions. This is how it will appear in process builder.
Some situation can not be handled just by config and will required apex code. Lets take a simple example when job status is closed the owner of position should be changed to ‘Closed_Positions’ queue. The @InvocableMethod annotation allows method to be called from process builder. While using the invocable method there are also certain limitations which you should be aware of. Here is how you can write invocable method
public class PBApexActionDemo
@InvocableMethod(label='Change Owner for closed position' description='Assigns the position owner to closed queue')
public static void changeClosedPosOwner(List positionIds)
List queue = [select id from group where name = 'Closed Positions' and type = 'Queue'];
List positions = [select id, status__c from Position__c where id in :positionIds];
List updatedPosition = new List();
if(position.status__c == 'Closed - Filled' && !queue.isEmpty())
position.ownerId = queue.id;
You must be wondering why write SOQL and not just pass on the position object reference from process builder in above code and change the owner id but that will throw an error ‘Record is read only’ when you try to update input positions in apex. The reason is that apex class has received the read only copy of record which is updated but not committed to database. This is exactly same like working in trigger after update and trying to modify Trigger.new which will throw an error ‘Record is read only’. The another solution if you don’t want to make SOQL call then Position object can be passed as an input and then clone it before making any update to it.
Here is apex action call from process builder:
In above example apex class PBApexActionDemo which has an invocable method taking position ids as an input. Then in ‘set apex variable’ section its referencing ids of positon to be passed into method. Remember you can have only one invocable method per class so no need to select any method with class to be invoked by process builder.
Tip: if you are converting existing apex trigger to process builder than make sure the field updated by original trigger are not used by subsequent trigger or workflow rule during transaction as processes will execute after workflow rules in sequence.
While enabling the ‘Recursion’ option for process builder the same record can only be re-evaluated 5 times in a transaction. If you have situation where same record needs to be re-evaluated more than 5 times by same process then make sure you are not exceeding this limit otherwise you might have unexpected result.
There are still many other scenarios where triggers are essential and process builder can’t meet the need. One of the scenario is having complex validation rules done in triggers can not be converted to process builder. Vote for my idea to add validation rules capability in process builder. Also delete/undelete operation’s before/after event handling can’t be performed via process builder.
There is lot more to write about various other capability of process builder which i will be putting into my subsequent post. Feel free to comment your thoughts on this post.