Posts by admin

Workflow vs Flows vs Process Builder vs Triggers When to use What?

December 10th, 2018 Posted by Uncategorized 0 thoughts on “Workflow vs Flows vs Process Builder vs Triggers When to use What?”

Automating business processes for your users can take your applications from:
“nice” —————————–to————————————–> “legitimately useful”


A savvy admin can save users time and clicks while creating consistency of processes and increasing data integrity, so mastering the tools available on the Salesforce platform can be very valuable to any organization

Lightning Flow:

Lightening flow provides declarative process automation for every Salesforce app, experience, and portal.
Included in Lightning Flow are two point-and-click automation tools:

  • Process Builder, which lets you build processes
  • Cloud Flow Designer, which lets you build flows

Let’s be clear.
Lightning Flow is a Product, and
Process Builder & Cloud Flow Designer are the Tools
What you Build is Processes and Flows

Workflow:

Workflow has been an admin’s friend for a long time. Workflows can:

  • Update a field
  • Send an email
  • Create a task
  • Send an outbound message (communication with another system)

 

These can be initiated when a record is:

  • Created
  • Created and everytime its edited
  • Created and everytime its edited to subsequently meed the criteria

Flow:

We can automate business processes by building applications, known as flows, that collect, update, edit, and create Salesforce information. Then make those flows available to the right users or systems

Flows can either require user interaction—perhaps a wizard or guided UI for data entry—or run in the background on their own—perhaps something that automatically transfers records when a user’s role changes

Use Cloud Flow Designer to:

  • Automate a guided visual experience.
  • Add more functionality for a behind-the-scenes process than is available in Process Builder. Build the more complex functionality in the Cloud Flow Designer. Then call the resulting flow from the process.
  • Start a behind-the-scenes business process when a user clicks something, like a button

For example, when an opportunity is won, your company wants a renewal opportunity to be created automatically. You can build parts of that use case as a process, but the rest has to be built in a flow

Process Builder:


Process Builder is a newer tool for admins which is even more powerful. In addition to everything a workflow can do (except for sending outbound messages), you can:

  • Create a record (not just tasks!)
  • Update related records (even child records!)
  • Send an Email
  • Launch a Quick Action
  • Post to Chatter
  • Launch a Flow
  • Call Apex code
  • Submit for approval
  • Invoke another process

Workflow

 

    • It can only update some fields on a parent record of a Master-Detail relationship
    • It cannot update multiple related records
    • *Admins have no control over the order of operations/actions
      It is used if the complexity of the process can be resolved using simple if-then statements
    • Workflow is not versioned
    • You can reference fields on the record’s parent
    • It starts when the record is saved/changed (insert/update)
      When utilizing formula in criteria, there is function help preview next to the syntax
    • It does not supports visual designer
    • You can edit a workflow even if it is activated

     

Process Builder

 

  • It can update any field on any related record
  • It can also update multiple related records in a situation when all of a record’s child records need the same update
  • *It gives admins the ability to set the exact order of operations
    Process Builder also has the ability to configure multiple if-then conditions in one Process rather than separate Workflow rules
  • Process Builder has versions, so you can retain deactivated Processes. This can be very helpful if you realize something isn’t working and want to look back to what was happening before
  • It lets you access the fields on any related record, no matter how far away that record is
  • It can start when record is changed or it can be invoked by another process or any Platform event occurs
    When utilizing formula in criteria, there is no function help preview next to the syntax
  • It has visual designer
  • User can’t edit process once it has been activated.Therefore much like with flow, a new process needs to be created by cloning the initial process and making modifications to that cloned records


* Because you can’t choose which workflow rule is evaluated first, choose one tool to automate everything for a given object. If you use both Workflow and Process Builder, you can’t reliably predict the results of a record change


Process Builder is the future
“We’re no longer enhancing Workflow. We still support your use of workflow rules, and will continue to do so. But all new functionality for the workflow use case will come through Process Builder. If you want to use the shiny new functionality, migrate your automation to Process Builder”
-Salesforce

Triggers:

A trigger is a feature of the Salesforce platform consisting of Apex code that executes before or after DML operations
Apex can be invoked by using triggers. Apex triggers enable you to perform custom actions before or after changes to Salesforce records.


A trigger is Apex code that executes before or after the following types of operations:

  • insert
  • update
  • delete
  • unDelete

For example, you can have a trigger run before an object’s records are inserted into the database, after records have been updated, before a record is deleted, or even after a record is restored from the Recycle Bin

Triggers Over Process Builder:

Note: Using Apex means that you’ll need to write test coverage and the more Apex you have, the longer it will take deployments from Sandboxes because the changes need to be validated against all of the code


Using Worflow, Process Builder and Trigger alltogether:

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. Soon process builder replace triggers for aforementioned operations

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

But there come certain situations where the above statement does not stand true, let’s see an example:

Let’s say you have an existing trigger on any object which is working fine.

trigger Vehicle_Trigger on SomeObj__c (before insert, before update, after insert, after update){
if(Trigger.isBefore){
//some code and SOQL statements
}
if(Trigger.isAfter){
//some code and SOQL statements
}
}

Whenever any record of custom object “SomeObj__c” is updated or created, above trigger will execute “two times” in before and after event

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


Let’s say after sometime, requirement came to calculate and update field on that 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 “SomeObj__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)

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


To make situation worst, if we write field update on same object “SomeObj__c” 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 “SomeObj__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

**** 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 ****


We could have converted the apex trigger into a workflow or a process bulder, but let’s assume it can’t be done or we don’t want to disturb our trigger

We could have avoid multiple execution of trigger by using static variable.

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.

In a nutshell, 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

By :-

Chirag Joshi

© Copyright Alien Brainz.  All rights reserved.