The document discusses different tools for automating processes in Salesforce - Workflow, Process Builder, and Apex - and provides guidance on which tool to use for different situations. It notes that Workflow is quick but limited, Process Builder can meet most needs but has scalability risks, and Apex can do anything but requires more effort. Key considerations for each tool include ease of use, functionality, scalability, debugging, and time to deploy.

1. USING THE
RIGHT TOOL
FOR THE
JOB
CHRIS BALDOCK - LINKEDIN.COM/IN/CHRIS-J-BALDOCK
SYDNEY SALESFORCE DEVELOPER MEETUP (15TH NOV 2018)

2. TWO COMMON MYTHS
• Always choose clicks over code
• Workflow is old news. Process builder all the way!

3. Name Presenter | xx Month 2016 |
OPTIONS
Workflow vs. Process Builder vs. Apex
• Workflow is quick to build, scalable BUT has limited functionality
• Process Builder / Flow can satisfy most requirements, is quick to build/maintain BUT has serious scalability considerations
• Apex can do pretty much anything, is scalable BUT requires additional effort to build/maintain

4. EXECUTION CONTEXT
What Happens When You Create/Update A Record
• Any Insert/Update made to a record kicks off a series of actions which together make up the “Execution Context”
• Any Workflow, Process Builder or Apex that is invoked can result in the consumption of governor limits
• Key Governor Limits which we need to be mindful of include (but are not limited to):
• Maximum 150 DML (inserts/update/delete requests) in a transaction
• Maximum 100 SOQL queries in a transaction
• Maximum 50,000 records queried by all SOQL within the transaction
• Maximum 10 seconds of CPU time for the entire transaction to complete
• Hitting platform limits within a transaction can/will break custom-built functionality
Special Note Regarding Workflow and Process Builder
• Workflow updates are fast and do not consume DML or SOQL (but do consume CPU and will kick of +1 round of triggers)
• Process Builder updates are slower and can have a multiplier effect on total DML and SOQL consumed

5. ORDER OF EXECUTION

6. WORKFLOW – HIGH LEVEL
Workflow Evaluated
• Ease Of Use: Very easy to build/maintain
• Functionality: Basic Record Updates, Email Alerts, Task
Creation, Outbound Messages
• Scalability: Consume no DML or SOQL
• Debugging: Very robust, unlikely to break
• Error Handling: Very robust, unlikely to break
• Performance: Fast
• Time To Deploy: Very quick to build / deploy

7. WORKFLOW - CONSIDERATIONS
Workflow considerations
• Don’t consume SOQL or DML limits!!!
• Fire after triggers
• Cannot handle delete and undelete DML
• Cannot control order in which Workflows fire
• Field updates skip validation rules
• Field updates result in Before Trigger and After Trigger firing once more (but only once more)
• Output actions limited to:
• Update Record or Parent Record (If detail in Master-Detail object)
• Create Task
• Send Email Alert
• Send Outbound Message
• Time-based action including any of the above
• Per Workflow, limited to:
• 10 Update Actions, 10 Create Actions, 10 Email Alerts, 10 Outbound Messages

8. USE WORKFLOW WHEN…
Some guidelines:
• You need to:
• Update Record or Parent M-D Record (up-to 10 per WF)
• Create Task (up-to 10 per WF)
• Send Email Alert (up-to 10 per WF)
• Send Outbound Message (up-to 10 per WF)
• There are no key dependencies between workflows (I.e. workflow B does not depend on the execution of workflow A)
• You understand that the field update or task insert will ignore validation rules

9. PROCESS BUILDER – HIGH LEVEL
Process Builder Evaluated
• Ease Of Use: Easy to build/maintain
• Functionality: Can meet most requirements
• Scalability: Risk of hitting limits if used improperly
• Debugging: Need to use error emails and debug logs
• Error Handling: Giant block of red error text
• Performance: Slow relative to Apex or Workflow
• Time To Deploy: Very quick to build / deploy

10. PROCESS BUILDER - CONSIDERATIONS
Process builder considerations
• Fire after triggers and workflows
• Cannot handle delete and undelete DML
• Scheduled record update actions skip validation rules (regular actions respect validation rules)
• No ability to catch and handle exceptions (so no ability to log or report on these exceptions)
• Slower than the equivalent function written in Apex which means an increased chance of hitting CPU limit
• Are subject to governor limits (unlike workflow):
• Each record Create action uses a single DML
• Each record Update action uses a single DML and a single SOQL query
• Each Post To Chatter, Submit For Approval, Quick Action uses a single DML
• Are not completely bulkified! https://success.salesforce.com/ideaView?id=0873A000000cM6iQAE
• Every update or create action will result in a new save procedure
• When coupled with triggers this can create a large multiplier effect on DML, SOQL and CPU!

11. USE PROCESS BUILDER WHEN…
Some guidelines:
• There exists no triggers for the object in question
• The object in question is not a core object (e.g. Account, Contact, Lead or Opportunity)
• Requirement cannot be met using workflow
• You understand the impact your process builder will have on governor limits
• You need to:
• Have branching logic e.g. perform different actions based on case status (Not possible in Workflow)
• React to the insertion of a Platform Event (Not possible in Workflow)
• Publish a platform event (Not possible in Workflow)
• Create record other than task (Not possible in Workflow)
• Update related record(s) other than parent in m-d relationship (Not possible in Workflow)
• Post to chatter (Not possible in Workflow)
• Initiate Process Builder (Not possible in Workflow)
• Initiate Flow (Not possible in Workflow)
• Initiate Quick Action (Not possible in Workflow)

12. APEX – HIGH LEVEL
Apex Evaluated
• Ease Of Use: Requires coding skillset
• Functionality: Can do pretty much anything
• Scalability: Consumes limits but provide granular controls
• Debugging: Granular debugging tools
• Error Handling: Granular exception handling
• Performance: Fast
• Time To Deploy: Slowest of the bunch to build

13. APEX – CONSIDERATIONS + GUIDELINES FOR USE
Apex considerations
• Require greatest effort to build and maintain
• All code must have >75% test coverage (though forces unit testing which is a good thing!)
• Are subject to governor limits (but make far more efficient use of limits vs. process builder)
Use Apex When:
• Building functionality for a core object (e.g. Account, Contact, Lead, Opportunity or any other that is solution critical)
• You need to satisfy a complex or detailed business process
• You need to perform validations across multiple objects
• You need to integrate with a third party system

14. EXAMPLE DECISION FLOW