https://trailblazercommunitygroups.com/events/details/salesforce-salesforce-developer-group-geneva-switzerland-presents-flows-what-you-should-know-before-implementing-virtual/

2. Doria Hamelryk

3. 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021
Why do you really need to know Flows as a developer?
Visual Flows in GA
New Flow builder
Einstein Next Best Actions
Scheduled Flows
Autolaunched Flows
Record Triggered Flows
Public Web Services Integration
Platform Events Flows

4. Flows & Trigger types
Manual
• Quick action
• Global action (with
component)
• LEX page component
(executed on load)
Scheduled
• Start/End date
• Frequency
Automatic
Autolaunched
Record Triggered
Platform Event Triggered
• Insert et/ou Update
• Before ou After
• Publication d’un
événement
Call from :
• Other Flows
• Button
• Apex

5. Focus on Elements

6. Lookup component
● Allows you to create a Lookup element based on the Lookup
field of an object
● All the fields of the chosen record are available in the Flow • The Lookup Filters are taken into
account at creation (Create Record
element) but not on display (Screen
element).
• No support for dependent Lookup Filters
• The user must have creation rights on
the source object ("Object API name"
field)
• Custom Lookup fields pointing to User
are not supported
• Only the first 5 results go up in the list
of records (matching based on the
Name field)
Points of attention
https://releasenotes.docs.salesforce.com/en-us/winter20/release-notes/rn_forcecom_flow_fbuilder_lookup.htm

7. Adding LWC to Flows
It is possible to create LWCs for Flows.
Minimum LWC settings for it to be
available in Flows:
● Target : lightning__FlowScreen
● isExposed : true
<?xml version="1.0" encoding="UTF-8"?>
<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata">
<apiVersion>49.0</apiVersion>
<isExposed>true</isExposed>
<targets>
<target>lightning__FlowScreen</target>
</targets>
</LightningComponentBundle>
https://releasenotes.docs.salesforce.com/en-us/winter20/release-notes/rn_forcecom_flow_fbuilder_solutions.htm

8. sObject in LWC for Flows
When using sObjects in LWCs, it is no longer
mandatory to restrict yourself to just one type of
object.
➔ Mutualization of certain components
<?xml version="1.0" encoding="UTF-8"?>
<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata">
<apiVersion>49.0</apiVersion>
<isExposed>true</isExposed>
<targets>
<target>lightning__FlowScreen</target>
</targets>
<targetConfigs>
<targetConfig targets="lightning__FlowScreen">
<propertyType name="ObjectType" extends="SObject" label="Objet" />
<property name="records" type="{ObjectType[]}" label="Records" />
</targetConfig>
</targetConfigs>
</LightningComponentBundle>
<template>
<lightning-datatable data={records} columns={colonnes} key-field="id">
</lightning-datatable>
</template>
import { LightningElement, api } from 'lwc';
export default class Mysobject extends LightningElement {
@api records = [];
@api colonnes = [{ label: 'Nom Record', fieldName: 'Name' }];
}
https://releasenotes.docs.salesforce.com/en-us/summer20/release-notes/rn_lc_flow_support_generic_sobject.htm

9. sObject in invocables actions
https://releasenotes.docs.salesforce.com/en-us/spring20/release-notes/rn_forcecom_flow_fbuilder_dynamic_types.htm
public with sharing class GetFirstFromCollection {
@InvocableMethod
public static List <Results> execute (List<Requests> requestList) {
List<SObject> inputCollection = requestList[0].inputCollection;
SObject outputMember = inputCollection[0];
Results response = new Results();
response.outputMember = outputMember;
List<Results> responseWrapper= new List<Results>();
responseWrapper.add(response);
return responseWrapper;
}
public class Requests {
@InvocableVariable(required=true)
public List<SObject> inputCollection;
}
public class Results {
@InvocableVariable
public SObject outputMember;
}
}
By using sObjects in classes, it is now possible to create
generic actions.

10. Conditional Visibililty
● Visibility can be configured on all screen
components.
● Based on AND / OR conditions.
● 10 conditions maximum, nestable according
to complex logics.
● A non-visible field configured as required,
does not trigger an error if it is not filled in.
https://releasenotes.docs.salesforce.com/en-us/winter20/release-notes/rn_forcecom_flow_fbuilder_conditionals.htm
Beware of LWC components (Lookup, custo picklist, etc.):
It is not possible to condition fields on their value, which is
only stored in the step following the screen component.

11. Elements Layout
Two modes are available in Winter ’21:
●The free mode, which we know today
●AutoLayout mode, which offers automatic organization of items
My Advice :
• Do not use, as long as it is not possible to
move the elements, and still in Beta

12. Decision refined like in Process Builders
Just as it was possible to decide in Process Builders, if an action should only be executed when the execution conditions changed from FALSE
to TRUE, Winter ‘21 offers the possibility of testing these conditions in the decision elements

13. Screen Flows – manually launched

14. Ways to get records and fields values
Selection :
Specific fields
Selection :
Specific fields
Storage :
Record var
(created by user)
Storage :
Multiple vars – one for each field
(created by user)
Selection :
All fields
Selection :
Specific fields
Storage :
Record Var
(created by system)
Storage :
Record Var
(created by system)
https://releasenotes.docs.salesforce.com/en-us/spring20/release-notes/rn_forcecom_flow_fbuilder_variables.htm

15. Pass Context in LEX pages
Variable Declaration (in Flow) LEX Page Setup Screen Flows Setup
IdRecord
https://releasenotes.docs.salesforce.com/en-us/summer20/release-notes/rn_forcecom_flow_fbuilder_pass_record.htm
Be carefull!
Update in Flow = Update in Layout
Update in Layout != Update in Flow

16. Pass context in Quick Actions
https://releasenotes.docs.salesforce.com/en-us/summer20/release-notes/rn_forcecom_flow_fbuilder_pass_record.htm
Variable Declaration Get Record Screen

17. Pass context in Quick Actions
Flow setup Quick Action setup Rendering
Id
https://releasenotes.docs.salesforce.com/en-us/summer20/release-notes/rn_forcecom_flow_fbuilder_pass_record.htm
If only record context needed :
No need to create custom
component anymore.
If other context needed :
Component will be needed, if not
available in Flows.

18. Launch Flow from Global Action
Today, Flows:
●are not available in Global Actions.
●must be called by Lightning components.
●cannot be called by LWCs.
The input variables must:
●Be declared in the Controller (init) before
launching the Flow.
●Receive the "name", "type" and "value"
elements
By default :
●The Flow will launch in Docker mode and not in
a modal.
●Once the Flow is finished, you will also have to
manage the closing of the component.
({
init : function (component) {
var flow = component.find("flowId");
var inputVariables = [ {name : "maVariable",type:'String',value:« valeur"}];
flow.startFlow("FluxGlobal",inputVariables);
}
})
<aura:component implements="flexipage:availableForAllPageTypes,[…]« access="global" >
<aura:handler name="init" value="{!this}" action="{!c.init}" />
<lightning:flow aura:id="flowId" />
</aura:component>
// Composant
<lightning:flow aura:id="flowData" onstatuschange="{!c.handleStatusChange}" />
// Controller
handleStatusChange : function (component, event) {
if(event.getParam("status") === "FINISHED") {
// Fermeture, redirection, Toast…
}
}

19. Scheduled Triggered Flows

20. Scheduled Flow
https://releasenotes.docs.salesforce.com/en-us/winter20/release-notes/rn_forcecom_flow_fbuilder_start.htm
The execution of scheduled flows falls within the global limitations of
asynchronous Apex executions,
i.e. 250k per rolling 24 hours (or 200x total number of licenses)
It is not possible to test scheduled flows, except by creating datasets,
and filtering the input records (or generating an error at the end of the
flow
Recommendation: Use this type of flow only on non-LDV objects
with a low frequency

21. Automatic Triggered Flows

22. Execution order and circular calls
System validation rules
Before Triggers
Custom validation rules
After Triggers
Assignement Rules
Workflows
Escalation rtules
Formula fields calculation
Flow in Before
Flow in After
Object
Case #1 :
2 Flows with updates on the same record
Execution: once per Flow
Object A Object B
Case #2 :
Flow with update from object A to object B,
and vice versa
Execution: once per Flow
https://releasenotes.docs.salesforce.com/en-us/spring20/release-notes/rn_forcecom_flow_fbuilder_before_save_updates.htm
Trigger on :
• Insert
• Update
• Upsert

23. Record-Triggered Flows launch condition
Recommendations: Do not use this functionality.
Reason:
It is necessary to maintain a single Flow Trigger per object and per
type, in order to manage the execution order of the different actions.
The conditions of application of actions within the Flow are to be
supported by "Decision" elements
Autolaunched
Flows
Autolaunched
Flows
Triggered
Flow

24. Performance Tests : Trigger vs. Automation
Trigger
(before insert)
Flow
(before sur insert)
Workflow Process builder
Min time 2058 2472 (+20%*) 4920 (+139%*) 9124 (+343%*)
Max time 2741 3756 (+37%*) 5899 (+115%*) 11558 (+322%*)
Avg time 2435 2969 (+22%*) 5367 (+120%*) 10049 (+313%*)
Performance tests:
• Performed on a creation of 2000 records
• Results over 10 iterations of tests
* Comparison with the execution time of the equivalent Trigger
Recommendation :
• Do not use Process Builder anymore !

25. Available actions according to the type of execution
Flow in Before Flow in After
Flow in Before:
• Only possible to update the current record.
• No further action possible.
Flow in After:
• Ability to perform more complex actions.
Pay attention to the order of execution: it is impossible to
manage the order of Flow Triggers
Recommendations:
• Only 1 Flow Trigger per object and per type (before / after).
• Only on low volume objects, without complex logic.
• No processing in the Flow in Trigger, only calls to Auto
Launched Flows.

26. Flow Trigger on before delete
In addition to the insert and the update, with the
Winter ’21, there is the possibility of managing
actions during deletion (before delete).
Please note, there is no possibility yet to manage
the Undelete, which will have to go through a
trigger.

27. AutoLaunched Flows
Autolaunched Flows are Flows, without Screen element, that can be launched from :
● Processus
● Apex Classes
● API REST
● Onglets Web
● Buttons or Links
● Visualforce Pages
https://releasenotes.docs.salesforce.com/en-us/winter20/release-notes/rn_forcecom_nba_call.htm
Do not mix Autolaunched Flows and Programmatic automation (class, trigger)
Use them to mutualize business processes between flows

28. Platform Events : publication & subscription
trigger eventMessage on MyEvents__e (after insert) {
for(MyEvents__e evt: Trigger.new){
// actions
}
}
trigger caseEvt on Case (after update) {
MyEvents__e evt = new MyEvents t__e();
evt.description__c = 'ma description';
EventBus.publish(evt);
}
Publication :
Subscription :

29. Platform Events (PE) : publication & subscription
Pay attention to the configuration of the
publication behavior!
In “Publish immediately" mode, transaction
limitations are not respected.
Platform events should be declared in “Publish
After Commit" mode to avoid these behaviors.
Process
PE publication
Create Task
Trigger on Task
Before Insert
Database
Commit
PE subscription
Read Task
Error
Process
PE publication
Create Task
Trigger sur Task
Before Insert
Database
Commit
PE subscription
Read Task

30. Subscriptions to PE through Flows
https://releasenotes.docs.salesforce.com/en-us/summer20/release-notes/rn_forcecom_flow_fbuilder_platform_event_trigger.h
Subscription to custom and standard events :
• AIPredictionEvent
• BatchApexErrorEvent
• FlowExecutionErrorEvent
• FOStatusChangedEvent
• OrderSummaryCreatedEvent
• OrderSumStatusChangedEvent
• PlatformStatusAlertEvent
If a Flow and a Trigger subscribe to the same event, it is not possible to
guarantee the order in which they will receive its publication.
Beware of infinite loops: a process subscribed to an event, which itself
creates this type of event, would loop.
Limitations:
• Definition of platform events: 50
• Active process subscribers per platform event: 2000
• Post / hour: 250k
• External subscribers (CometD): 1000 in total
• External notifications per 24h: 25k

31. Execution Mode and Permissions

32. Execution mode in Flows
3 execution modes :
● System with sharing
● System without sharing
● User- or Context-Dependent
https://releasenotes.docs.salesforce.com/en-us/spring20/release-
notes/rn_forcecom_flow_fbuilder_system_mode.htm
https://help.salesforce.com/articleView?id=flow_distribute_context.htm&type=5
Beyond the record visibility, it is
necessary to take into account the
behavior of Flows regarding
Permissions on objects and fields

33. Execution mode : Lightning Pages
User or System
Context
System without sharing System with
sharing
VISIBILITE Sharing : user Sharing : system Sharing : user
PERMISSION Object/FLS : user Object/FLS : system Object/FLS : system
Lightning Page
Screen
Flow
The Flow configuration will determine the visibility on records (with / without sharing) and permissions on fields /
objects (user / system).
When the Flow is set to Context mode, the visibility and permissions will be those of the user running the Flow

34. Execution mode : Parent / Child Flow
Page Lightning
Main Flow :
Screen Flow
Child Flow :
Autolaunched
Flow
VISIBILITE User or System
Context
System without sharing System with
sharing
Flow parent – Context Sharing : user Sharing : system Sharing : user
Flow parent – without sharing Sharing : system Sharing : system Sharing : user
Flow parent – with sharing Sharing : user Sharing : system Sharing : user
PERMISSION User or System
Context
System without sharing System with
sharing
Flow parent – Context Object/FLS : user Object/FLS : system Object/FLS : system
Flow parent – without sharing Object/FLS : system Object/FLS : system Object/FLS : system
Flow parent – with sharing Object/FLS : system Object/FLS : system Object/FLS : system
The configuration of the child Flow will determine the visibility on the records (with / without sharing) and the permissions
on the fields / objects (user / system).
When the child Flow is set up in Context mode, the setting of the parent Flow will be taken into account.
If the parent and child are both in Context mode, the visibility and permissions will be that of the user running the Flow

35. Execution mode : Impact on LWC and Classes
VISIBILITE User or System
Context
System without sharing System with
sharing
Class with sharing Sharing : user Sharing : user Sharing : user
Class without sharing Sharing : system Sharing : system Sharing : system
Page
LightningScreen
Flow LWC Class
PERMISSION User or System
Context
System without sharing System with
sharing
Class with/without
sharing
Object/FLS : system Object/FLS : system Object/FLS : system
As standard, classes called from LWC components do not take permissions
into account:
PERMISSION User or System
Context
System without sharing System with
sharing
Class with/without
sharing
Object/FLS : user Object/FLS : user Object/FLS : user
When testing the permissions via the isAccessible () function, the current
user is always taken into account, regardless of the Flow execution mode:
Visibility on records will be determined by the
class declaration (with / without sharing)
User permissions on fields / objects will be:
• Bypassed when no test is done via functions
such as isAccessible (), ...
• Respected, if we test accessibility
And this; regardless of the execution mode of
the Flows

36. Execution mode : Autolaunched Flows from methods
VISIBILITE User or System
Context
System without sharing System with
sharing
Class with sharing Sharing : system Sharing : system Sharing : user
Class without sharing Sharing : system Sharing : system Sharing : user
Trigger Class
Autolaunched
Flow
PERMISSION User or System
Context
System without sharing System with
sharing
Class with/without
sharing
Object/FLS : system Object/FLS : system Object/FLS : system
The visibility on the records will be determined by the execution mode of the
Flow (with / without sharing).
In Context mode, visibility is identical to System without sharing mode
Field / object permissions will always be in system mode, regardless of the
Flow execution mode

37. Test & Deploy

38. Debug flows & running user
With Winter ‘21, it is possible to test Flows by
simulating execution by a chosen user.
This will allow you to have better control over the tests
for the different profiles.
This option must be activated in:
Setup > Process Automation Settings> Let admins
debug flows as other users
User must have view all data permission !

39. Debug AutoLaunched Flows

40. Deployement and Test Coverage
● The minimum test coverage of 75% excludes the Flux test
coverage.
● For active Flows, it is possible to define a minimum test
coverage percentage specific to Flows.
● Access to the configuration from "Process Automation
Settings” in the Configuration
https://releasenotes.docs.salesforce.com/en-us/winter20/release-notes/rn_forcecom_flow_mgmnt_coverage.htm

41. Other features subject to a pilot
Public Web Services available in Actions
● Jira, Dropbox, Instagram, Twitter, Mailchimp, eBay, Walmart,
GoToMeeting, Trello, Medium - 25 actions max. à la fois par API
Multi-column screens
● Configurable by section