Why to avoid using Workflow rule and Process Builder field update with Trigger

Workflow rule and Process builder are the tools because of which Salesforce Admins can perform so many tasks, which were only possible by writing Triggers. Before release of Process builder, if we wanted to perform field update on child records or post chatter messages or auto execute Visual Flow, Triggers were used by developers.

As a best practice in Salesforce, it is always suggested that we should prefer “point and clicks” over code. Indirectly, prefer Workflow rule or Process builder over Triggers.

Trigger Workflow and Process Builder in Salesforce
Trigger, Workflow and Process Builder in Salesforce

In this post, I will explain a scenario where above statement will not stand true.

Using Trigger

Lets consider that there is a trigger written on custom object “Vehicle__c”. For simplicity, below trigger just have some debug statements.

trigger Vehicle_Trigger on Vehicle__c (before insert, before update, after insert, after update) {
    
    if(Trigger.isBefore){
        //some other code and SOQL statements
        System.debug('******** - In Before Update Trigger');
    }
    if(Trigger.isAfter){
        //some other code and SOQL statements
        System.debug('******** - In After Update Trigger');
    }

}

Whenever any record of custom object “Vehicle__c” is updated or created, above trigger will execute “two times” in before and after event. To know more about sequence of execution of trigger, you can refer this link.

output :

******** - In Before Update Trigger
******** - In After Update Trigger

Trigger and Workflow field update

Let’s say after sometime, requirement came to calculate and update field on Vehicle object. Considering timeline to deliver this requirement, team decided to choose Workflow field update over modifying existing trigger. Consider that workflow rule is written to execute every time when record is either created or updated.

Now, whenever any record of custom object “Vehicle__c” is updated or created, chances that trigger will execute will be “four times” because of sequence of execution.

When record is created or updated trigger will execute twice (before and after event) and after that workflow field update will cause trigger to execute again (before and after event).

output :

******** - In Before Update Trigger
******** - In After Update Trigger
... WF rule operation if condition meets ...
******** - In Before Update Trigger
******** - In After Update Trigger

Trigger, Workflow and Process builder field update

To make situation worst, if we write field update on same object “Vehicle” in Process builder also then trigger may execute “six times” instead of only two times.

In this case, whenever any record is created or updated on custom object “Vehicle__c” then trigger will execute twice after that workflow field update will cause its execution again. After workflow field update, process builder will update record again causing execution of trigger again.

Difference between Workflow and Process builder field update

If field update is done using Process builder, then record will go through complete Save cycle again.

If field update is done using Workflow field update, then Custom validation rules, duplicate rules, and escalation rules will not run again. Read here more.

We can avoid multiple execution of trigger by using static variable (Question 26). However, if trigger is already written then instead of creating workflow or process builder field update, its wise decision to use existing trigger for field update. Multiple execution of trigger could cause hitting various governor limits like SOQL query or concurrent apex limit.

output :

******** - In Before Update Trigger
******** - In After Update Trigger
... WF rule operation if condition meets ...
******** - In Before Update Trigger
******** - In After Update Trigger
... Process builder if condition meets ...
******** - In Before Update Trigger
******** - In After Update Trigger

Roll-Up Summary Field and its implications

If trigger is written on Master object and “Roll-Up summary field” is created on it. If child record creation , updation causes Roll-Up summary field to recalculate, then parent record undergoes through save operation causing its trigger to execute again.

In short, having trigger, workflow and process builder field update on same object at same time (same condition) is not a good idea and it should be analysed carefully before deploying to production.

Posted

in

by


Related Posts

Comments

19 responses to “Why to avoid using Workflow rule and Process Builder field update with Trigger”

  1. Steve Avatar
    Steve

    Then the purpose of using declarative features (as possible) defeated easily.

    One of my client has 2 processes, 40+ workflows (field updates& email alerts), one trigger(9 SOQL) for single object.

    Working on removing the process and subsequently all the WFS ;( Thanks a lot for this post, feel like a dumb after seeing this.

    1. Jitendra Zaa Avatar

      WF and Process builder can do some other operations than Field update. If there is field update and no trigger then declarative is suggested. But in your case, it seems you need to move WF field updates in trigger itself. I am glad this post came handy for you.

  2. Pat Vachon Avatar
    Pat Vachon

    This seems incorrect on the Process Builder part as per the orders of execution documentation from Salesforce.
    https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm

    1. Jitendra Zaa Avatar

      If you try to run above example, you will see above logs. If process builder updates any record, then that record undergoes save operation again calling triggers.

      1. Pat Vachon Avatar
        Pat Vachon

        Strange. According to this, then the orders of execution needs to be updated?

        1. Jitendra Zaa Avatar

          Agree… In fact Process builder will act only if we are updating field of current record. For other types of operations like email, chatter it will not impact.

  3. Samuel De Rycke Avatar
    Samuel De Rycke

    Consider that many trigger operations could be moved to Declarative process builder or process builder apex actions through InvocableMethods. I think those are processed asynchronously in a different cycle or is that incorrect ?

    1. Jitendra Zaa Avatar

      Tested “InvocableMethod” scenario as well, However It executed “synchronously”. Checked documentation as well, it doesn’t says that it executes asynchronously.

      1. Samuel De Rycke Avatar
        Samuel De Rycke

        Thank for that!

  4. sreeharini Avatar
    sreeharini

    Hi Sir,
    I am a beginner in salesforce. Can you please explain me what is the difference between Process builder’s submit for approval and Approval processes? If a record is submitted through process builder, to whom it will be assigned for approval?

    1. Jitendra Zaa Avatar

      Hi Sree, Using Process builder you can only invoke Approval Process. “Who will be assigned” , would be decided by approval process defined.

      1. Sreeharini Avatar
        Sreeharini

        Thank you so much for clarifying.

  5. Srinivasu Avatar
    Srinivasu

    Hi,

    Using process builder, can we create a record with a specific owner and also send email alert to that owner in the same transaction..i created a process builder which creates another record and also assigns to the right owner as specified in the field mappings, but the email alert after the create record is not triggered. Appreciate any help or pointers on this.
    Srini

  6. Gopala Karthigai Selvan Murugesan Avatar
    Gopala Karthigai Selvan Murugesan

    Hi Jitendra,

    Is there a way to exclude process builder execution if a particular roll-up summary field is updated in parent object?

    Regards,
    Gopal

  7. Kevin McAuliffe Avatar

    Good article. There are some other declarative features in salesforce that can set field values for narrow use cases. Assignment rules will set the owner field for Cases and Leads. Email-to-case will set the record type, Case Origin, and Case Priority. I have used these along with Apex Triggers and not had any trouble. I believe they only fire “on insert.” Should we consider these “rules” in the same category as workflow rules, and try to avoid combining with Apex triggers that fire on insert?

  8. Lokesh Avatar
    Lokesh

    Thanks Jitendra,
    This saves my time as I was about to start my R&D on this area, luckily found this article.

  9. […] Why to avoid using Workflow rule and Process Builder field update with Trigger […]

  10. PRR Avatar
    PRR

    Hi Jitendra,
    Is it better approach to completely use process builders instead of trigger as
    we have In vocable methods to process the complex logic through process builder except for delete events.

  11. Giri Prashanth Kaliki Avatar
    Giri Prashanth Kaliki

    Hi Jitendar,

    If we have like multiple workflows and multiple process builder on the object where they are performing field updates on the same object. How many times the trigger fires is it only once per all process builders and once workflows. or is it like multiplication of number of process builders or workflow ex: if there are 5 workflows and 3 process builder will the trigger fire like 8 times?

Leave a Reply to Jitendra ZaaCancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Discover more from Jitendra Zaa

Subscribe now to keep reading and get access to the full archive.

Continue Reading