In Winter ’23, you can now drop an LWC version of the Flow component into your own LWC’s, allowing you to build components that embed screen flows. Here’s an early look at the documentation. Let us know if find any bugs!

---

A lightning-flow component represents a flow interview in Lightning runtime. To use this component, build a flow with the Salesforce Flow Builder first.

To create a flow in your component, set the lightning-flow component’s flowApiName attribute to the name of the flow that you want to use. The component includes navigation buttons (Back, Next, Pause, and Finish), for users to navigate within the flow.

This example creates and starts the Survey Customers flow.

<template>
    <lightning-flow
        flow-api-name='Survey_customers'
    >
    </lightning-flow>
</template>

You can provide initial inputs for the interview by setting the flowInputVariables attribute to an array of input values.

This example creates and starts an interview by passing in initial values for the flow. It handles a change in the interview using the onstatuschange event handler.

<template>
    <lightning-flow
        flow-api-name='Survey_customers'
        flow-input-variables={inputVariables}
        onstatuschange={handleStatusChange}
    >
    </lightning-flow>
</template>

get inputVariables() {
    return [
        {
            name: 'OpportunityID',
            type: 'String',
            value: '<Opportunity.Id>'
        },
        {
            name: 'AccountID',
            type: 'String',
            value: '<Opportunity.AccountId>'
        }
    ];
}

handleStatusChange(event) {
    if (event.detail.status === 'FINISHED') {
        // set behavior after a finished flow interview
    }
}

Usage Considerations

Thelightning-flow component only supports active flows for the flowApiName attribute.

The onstatuschange event returns these parameters.

Parameter	Type	Description
activeStages	Object[]	The current value of the $Flow.ActiveStages variable in the flow. Available in API version 42.0 and later.
currentStage	Object	The current value of the $Flow.CurrentStage variable in the flow. Available in API version 42.0 and later.
flowTitle	String	The flow’s label.
helpText	String	The help text for the current screen. Available in API version 42.0 and later.
guid	String	The interview’s GUID. Available in API version 42.0 and later.
outputVariables	Object[]	The current values for the flow’s output variables.
status	String	The current status of the interview.

These are the valid status values for a flow interview.

• STARTED: The interview is started and ongoing.
• PAUSED: The interview is paused successfully.
• FINISHED: The interview for a flow with screens is finished.
• FINISHED_SCREEN: The interview for a flow without screens is finished.
• ERROR: Something went wrong and the interview failed.

Customizing a Flow’s Finish Behavior

By default, a finished flow without screens displays the message “Your flow finished.” A finished flow with screens returns users to the first screen for a new interview.

Change this behavior with the flowFinishBehavior attribute to manage whether a new interview should restart or only run once.

These are the valid flowFinishBehavior values.

• NONE: The flow only runs once.
• RESTART: The flow restarts once it has finished.

To customize what happens when the flow finishes, add an event handler for the onstatuschange action when the status value contains FINISHED.

When flows run, what they’re allowed to do depends on their permissions, and those are based on the concept of the ‘running user’. For some kinds of flows, this can be pretty obvious. When screen flows execute, the running user is the User who is currently logged into Salesforce when the flow is initiated. For others, it’s a little more nuanced. Take record-change triggered flows. One might guess that the owner of the record that changed would be the running user, but it’s actually the person whose action triggered the record change that determines what the flow can or cannot do. Then there’s the question of Schedule-triggered flows, where there really isn’t any obvious user to assign.

When Schedule-Triggered Flows were first released, they were built to use a special, hidden user called the Automated Process User (“APU” and sometimes referred to as the Autoproc user). The APU has been around for many years and is used in places other than Flow including Apex and Flow Orchestration. However, APU has some limitations. It doesn’t show up in places like Profiles and Permission Sets so it’s hard to assign specific permissions to it. It doesn’t have access to ConnectAPI’s which are used in a lot of Salesforce services.

Changing APU would be challenging because it’s enmeshed in a lot of different parts of Salesforce. And it would still have limitations: you might not want the permissions for your Scheduled-Triggered Flows to be the same as your Platform-Event Triggered Apex Triggers, for example, but there’s only one APU, even if you had an easy way to change its permissions.

So, the Automation group introduced a new concept: the Default Workflow User. This is just a pointer to a User account. Whatever permissions you give that User are exactly what your Schedule-Triggered Flows can do.

Let’s go into more detail.

Default Workflow User is the recommended way to control the access level of automations for Schedule-Triggered and Record-Triggered Flows

You assign a User to be the Default Workflow User in Setup → Process Automation Settings:

As you can see, the Default Workflow User becomes the running user of Schedule-triggered flows.

This feature was added in October, 2021 (API Version 53). Flows saved to earlier versions will continue use the Automated Process User. You can resave a flow to a later version number if you want to change this.

Orchestration, Apex, Platform Events, and More Use the Automated Process User

Flow Orchestration

Flow Orchestration uses the Automated Process User to send notifications. Note that in order to get the Automated Process User to successfully send email, you need to specify an existing Organization-Wide Email Address (i.e. the ‘From’ Address that your org will send as). That’s done here in Process Automation Settings:

Note that you can’t just type any email address in there. You have to go to Setup, configure an Organization-Wide Email Address, and confirm it. Once that’s done you can enter the email address in Process Automation Settings.

Apex

Apex triggers set to fire on the receipt of a Platform Event Triggers also use the Automated Process user. This knowledge article is old but may be useful.

Some Apex methods execute as the Automation Process User, such as this SandboxPostCopy interface that enables a class to be executed immediately after sandbox creation.

Other Services That Use Automated Process User

• Approval Process Knowledge Actions
• Automation triggered by Batch Uploading of Records, such as Duplicate Rules Management. (Discussion)

Platform Events and the Automated Process User
When automation is triggered by a Platform Event, the running user actually varies depending on what’s triggered:

• Traditional Apex Triggers execute as the Automated Process User, as described above.
• Process Builder processes execute in the context of the user who fired the platform event (although they still show up in debug logs as the Automated Process User) (documentation)

As this knowledge article explains. The limitations on access that the Automated Process User normally encounters can cause Apex Triggers to behave oddly, and better results might be obtained by switching to a process from Apex.

The Automated Process User will trigger follow-on automation, such as workflow rules, validation rules, and flows, unless it has been assigned a more limited permission set, as described below.

Access and the Automated Process User

Triggered flows that use the Automated Process User run a flow in System Context without Sharing, which is the highest amount of access. However, there are some things that Automated Process User doesn’t have access to by default, such as Connect API’s.
It is possible, however, to assign a permission set to the APU. You can’t do it in Setup UI, but you can use Developer Console to assign a permission set to the User that has an alias of ‘autoproc’:

insert new PermissionSetAssignment(
   AssigneeId = [SELECT Id FROM User WHERE alias = ‘autoproc'].Id,
  PermissionSetId = ‘<your Permission Set Id here>’
);

Kudos to Roy Lloyd and Dan Moore for figuring this out! Keep in mind that if you follow recommendations and use Default Workflow Users you won’t have to do this.

Tracking the Automated Process User
You can log information about the Automated Process User in Setup →Environments → Logs → Debug Logs and you can see it in the View Setup Audit Trail (credit to Bill Wu for this information):

Note that if you have Sharing set to Private as an Organization-Wide Default, records owned by the Automation Process User will not be visible generally. However, there’s a setting that you can opt to use that will help with this. This is discussed here and addressed in this Spring ’22 improvement.

More on Automated Process User and Setup Audit Trail

Record-Change Triggered Flows Usually Have a Running User That They Can Use

Record change triggers normally use the Running User to determine access, for both the immediate automation and for any scheduled-paths. This is the User that initiated the record change (e.g. the logged in user editing a record in the UI, or the logged-in user making an record-update API call). For scheduled-paths, however, if that user has been deactivated (presumably in the interval between the record save and the scheduled-path execution), it switches to the Default Workflow User (with secondary fallback to Automated Process User if Default Workflow User is somehow not set, although an activation warning is issued on save if it isn’t set).

Learn More

Flow and Contexts

Check out this sneak preview of what’s slated to come in the Winter ‘23 release! 

Note that this is not a complete list of changes and you should carefully check the Release Notes for changes that may impact your org.

Data Table (Beta) Arrives!

You know it, you love it, you need it – an out-of-the box Data Table comes to Flow! Select your fields, your records you want to display, and let your users act on those records in any way you want.

Data Table (Beta) Features

• Table Header: Create an accessible label for your table and hide it from users so that it remains accessible.
• Single Record & Record Collection Outputs: Selected records from the Datatable will be available as both a Record Collection and a Record Resource. 
  • Note: One key feature we built in is the ability to have ‘uncommitted’ records not in the database displayed on a table – A great way to implement confirmation screens where your users build collections of data in Flow before creating them in the database!
• Selection Modes: Change the table selection mode to Multi-select (Checkbox), Single Select (Radio), or No Selection (View only)
• Required Selection Options (Min and Max): Ensure your users select the records you want by enforcing a minimum or maximum selection of records. When in Single Select mode, this changes to a ‘Required Selection’ checkbox.
• Default Selection: Provide a record collection to act as a default selection upon entering the screen
• Column Configuration
  • Drag/Drop Fields: Select the fields you want to display from the Record Collection’s object you choose in your table and drag and drop the column order all within the property editor 
  • Custom Header Labels: You can provide an alternative field label for any field you display to your users. This is especially important when displaying data to external users. 
  • Wrap/Clip Text: You can choose whether a field will wrap or clip its contents within the table. The default is Clip. 
• Rich Text Field Support: The base lightning-datatable component does not support rendering rich text, but we built it in! You’ll be able to create beautiful looking tables that contain images and bulleted lists for richer screen experiences, including formula fields!

For much more about Data Table, see The Three Musketeers Arrive in Winter ’23: Data Table (Beta), IN Operator, and Record Type Filtering for Picklists

IN / NOT IN Operator Support for Get, Update, Delete Elements

At long last, the ‘IN’/’NOT IN’ Operators arrive to Get Records, Delete Records, and Update Records elements. Get rid of those nasty queries within your loops and scale with higher data volumes with these new operators. For those unfamiliar with an IN operator, the best way of describing it in words is something to the effect of “I want to retrieve or do something on a collection of records based on this set of values”. You’ll now be able to do a query like “Get me all Contact Records IN this collection of country names” or “Get me a list of all Accounts using the AccountIds of these opportunities”.

How It Works

In this first release, you can use any non record-collection on the right hand side of an IN statement – examples include a Text Collection, Date Collection, or a Number collection. The best way of describing ‘IN’ functionality is something to the effect of  “I want to retrieve or do something on a collection of records based on a set of values”. It is the best friend of Junction Objects. 

In a screen flow scenario, imagine running a screen flow where you want to display a Data Table of Contact records based on the Related Contacts for an Account. Those relationships are actually stored in the Account Contact Relationship junction object. In other words, what you actually want is “Show a list of Contacts that are in the list of Active Contact Relationships related to the account.” With IN, this is now possible without doing queries within loops.

Speaking of loops, you often hear “don’t put queries in your loops”. Until now, you really didn’t have a way to avoid that. Imagine a record-triggered flow scenario where an Opportunity closes and you want to update a field on a set of Account Team records for each person on the Opportunity Team. Before, you had to loop over the Opportunity Team and within the loop, query for a related Account Team member record. With ‘IN’, you aren’t forced into querying within your loop and can just query for the relevant Account Team members directly.

For more about IN Operator, see The Three Musketeers Arrive in Winter ’23: Data Table (Beta), IN Operator, and Record Type Filtering for Picklists

Record Type Filtering for Picklists in Dynamic Forms for Flow

Picklists in Dynamic Forms for Flow are now record type aware upon entering the screen!

If a record resource has its RecordTypeId field set when entering a screen, any picklist values that are dependent on a record type will now display the correct picklist values. If no record type id is set, the picklist will display all values. This addresses a 12,000+ IdeaExchange idea and long-standing Flow request that we are excited to deliver for you.

For more about picklists with record-type awareness, see The Three Musketeers Arrive in Winter ’23: Data Table (Beta), IN Operator, and Record Type Filtering for Picklists 

Formula Checking Now Available Everywhere in Flow Builder

We released our new Formula checker in Summer ‘22 for Record Triggered flow Entry Criteria and have now expanded it to formula resources and Collection Filter! Validate that your formulas are in the correct format before saving your flow for a fantastic time-saver and peace of mind.  

Flow Builder

Search When Adding an Element in Auto-Layout

When adding new elements in Auto-Layout, you’ll now be able to search across all flow elements and actions to quickly find what you need. Note that it even shows custom actions (like those found here on UnofficialSF)! 

Cut and Paste Single Elements in Auto-Layout

Need to move an element in Auto-layout? Take advantage of cutting and pasting individual elements in Flow without switching into free form.

Ability to Hide Resource Panel / Hidden by Default

When in Auto-layout, the resource panel will now be hidden by default and can be expanded/collapsed to save screen real estate when you need to view more of your Flow.

Screen Flows

Dynamic Forms for Flow Goes GA

Drag in your record fields directly into screen flows with Dynamic Forms for Flow, now GA! We spent this release polishing up under-the-hood with some added features, discussed below and will continue to bring more field types to Dynamic Forms over time. 

Record Type-Aware Picklists

As noted in The Three Musketeers Arrive in Winter ’23: Data Table (Beta), IN Operator, and Record Type Filtering for Picklists, Picklists from records in Dynamic Forms for Flow will now be filtered by record type if the record resource has a valid record type Id set. 

Easier Record Resource Creation

When creating a new record resource from the Fields tab, we now automatically jump you to the right resource (Variable -> Record) type. Before, you had to go through a number of hoops before getting to the right resource type. This will make the process far easier for newer users and far faster for experienced builders.

Field Visibility Now Fully Supported

Before this release, conditional field visibility did not react to conditions that referenced components or fields that were on the same screen. Now, conditional field visibility in Dynamic Forms for Flow now behaves as expected.

Bigger Screen Editor

Open up the screen flow editor – notice anything? Yep – we’ve now made the screen editor significantly larger, giving you more space to create awesome Screen Flows. 

Lookup Enhanced to Support Multiple Records

Ever wish your users could select multiple records with the Lookup component? Is a Data Table too much for some basic use cases? Users can now select multiple records with the Lookup screen component! You’ll now notice two new inputs: Maximum Selections and Record ID Collection

• To enable multi-select, you need to set the new ‘Maximum Selections’ input to a number greater than 1.
• The Record ID Collection input is used to set a default selection or ensure values persist if a user resumes the flow or navigates back to the screen. 
• The component now outputs the selected Ids into a Text Collection – Record ID Collection.

Pair with ‘IN’ Operator

This new multi-select capability pairs nicely with the new ‘IN’ operator – Just perform a Get Records to convert the user’s selection (a Text Collection of Ids output) into a workable record collection:

Choices Now Support External Data (Apex-Defined Types)

The Apex-defined data type affords you a flexible way to represent complex data that isn’t well-modeled by the sObjects in your organization.  Customers often use the Apex-defined data type to represent external web objects, so that they can integrate with external web services either entirely declaratively through Flow and External Services, or with a mixed code & clicks pattern through Flow and invocable Apex.

Now, you can represent your external data as Choices using Collection Choice Sets that are Apex-Defined Types.

Embed Screen Flows from LWC Components With the New ‘lightning-flow’ Component

You can now embed Flows directly from LWCs! Reduce your Aura footprint and offload pieces of your custom components to Flow with the new lightning-flow component. 

The component behaves virtually the same as the aura lightning:flow component with one exception – in the LWC version we’ve resolved an issue with finish behavior that consumed unnecessary FlowInterview instances under certain conditions.

Record-Triggered Flows

‘Update Related Records’ Comes to Record-Triggered Flows

One of the few remaining gaps with Process Builder is the ability to easily update Related Records of the triggering record. While it was possible before, users coming from Process Builder may find this method more at home.

Now, you can select a new option in an Update element in a record triggered flow: Update records related to the [object] record that triggered the flow

From there, you can then select the relationship, or children, you want to update:

As with Process Builder, you will also be able to specify criteria for which children to update. Take for example a situation where you wanted to update all of the child accounts of an account where the Account Source = Advertisement below:

Workflow Rule Creation Now Disabled

The Create New Workflow Rules button will be removed for most people in Winter ‘23. It’s time to move to Flow!

No-Code Testing Goes GA 

No-code testing is now Generally Available, and with it, comes support for creating Scheduled Path tests and packaging compatibility. 

Admins can now create automated tests to ensure their Flows don’t break when other members of their team (or their future selves) make changes.

Flow Tests allow you to set up assertions or ‘assumptions’ about your results that you want to always stay the same. Those assertions protect your future self or others on the team from making costly mistakes in the future. 

Flow Orchestrator

Create Reports on Flow Orchestration Objects

Gain insight into pending and completed work items to gauge how well your Orchestration is performing by creating reports. Users with the appropriate permissions can now create reports that include Orchestration Runs, Stages, Steps, and Work Items.

Work Guide Now Refreshes Page When an Interactive Step Finishes

When a user with an assigned step finishes the screen flow, the screen will automatically refresh and progress to the next step (or finish, depending on the orchestration). Before, they had to manually refresh the page. 

Work Guide Now Available in Experience Cloud Sites

Place the work guide component in your Experience Cloud site record pages to enable your credentialed external users to complete work guide steps. 

Use Subflows in Evaluation Flows

When using evaluation flows to control your entry/exit criteria between stages, you can now use the Subflow element to re-use common evaluation criteria. Note that only other evaluation flows can be used as a Subflow.

Sharing Rules for Orchestrator Objects (Release Update)

You can now determine who can see Flow Orchestration objects by creating sharing rules! After enabling the release update, the Manage Flow user permission no longer grants users access to Flow Orchestration objects. Users who run orchestrations and execute work items must still have the Run Flows user permission.

Record Owners for Orchestration Objects

Now that many of Orchestrator’s objects are available we also made it so that they all have appropriate record owners. For more details, check the release notes when they arrive.

Flow & Slack Integrations

Screen Flows in Slack Can Now Take Simple Text Inputs & Support More Data Types

Screen Flows launched in Slack can now take basic input parameters such as recordIds, making it far easier to tailor your screen flows that you send to users in Slack!

Additionally, Screen Flows in Slack can now use Date, Date Time, Checkbox, and Checkbox Group input types.

Other

Call Invocable Actions from Apex Goes GA

Previously a developer preview, Apex developers now have the ability to call a subset of standard and custom actions directly from their Apex code, bringing the diverse capabilities of invocable actions to Apex developers.

Considerations

Invocable actions that do their own commit operations cannot be called from Apex. The following standard actions are callable from Apex in Winter ‘23:

• apex, flow
• chatterPost
• runExpressionSet, runDecisionMatrix
• activateSessionPermSet, deactivateSessionPermSet
• getAssessmentSummary

Additional standard actions will be callable from Apex in future releases!