Managing a flow

Like any other automation process, a flow can be activated and deactivated. It supports versioning (and so cloning is a good choice if you wish to experiment with different versions) and, as in Process Builder, only one version of a flow can be active at a given time.

A flow can be distributed in the following ways:

• A Lightning page using the standard flow component from the Lightning App Builder
• A record quick action using the Flow action type
• In the Lightning Console
• In the utility bar so that the flow is available from any page of the given Lightning app
• By URL (for more details, please refer to https://help.salesforce.com/articleView?id=flow_distribute_internal_url.htm&type=5)
• Using a custom Aura component (ask your developer about how you can do this)
• Using a custom Visualforce page (ask your developer about how you can do this)
• Using Process Builder, a workflow with a flow trigger (beta feature), and Apex and REST APIs for autolaunched flows

When a flow fails, Salesforce sends a detailed email to the admin who last modified the flow or to the Apex exception mail recipients (this can be set up from Setup | Email | Apex Exception Email). You can choose which recipients to use from Setup | Process Automation | Process Automation Settings:

Flow error email recipients definition

I suggest that you select Apex Exception Email Recipients to prevent common users from receiving error log mail messages.

Testing a flow

As with any other feature, before releasing a flow into production, remember to test any available path so that you don’t run into any unexpected surprises.

Debugging a flow is quite straightforward; select a flow and click on the Debug button. A new window will open:

Flow debugging options

If the flow has inputs that are not collections or record variable resources, you can set them up on this initial box (like in the picture above).

When you click Run, the flow is executed. On the right-hand side of this window, you can take a look at the whole context:

Debugging a flow

After each Next click, you’ll see the right-hand side being updated with new data for each element that composed the flow.

Remember that, even in debug mode, transactions are committed to the database, so be careful when debugging in production.

Transactions and governor limits

Do you remember what we said about governor limits for Process Builder?

The same considerations apply for flows as well.

DMLs (or update/create/delete actions) are done when we use Create/Update/Delete Records elements or Actions (such as quick actions to create a Chatter post), while SOQL queries are done when using, for example, the Get Records element.

One of the best coding practices is to bulkify coding, that is, avoiding repetitive SOQL queries or database operations one after the other and preferring to use a single database operation to commit more than one record at a time.

The cool thing about flows is that their engines are automatically bulkified, so if you make a Create Records element that executes after a massive record operation on the system (for example, massive data loading that triggers for each record of Process Builder that calls a flow action), then chances are, the system will bulkify the flow interviews, thereby keeping your transactions under governor limits as much as possible.

For more details about flow bulkification, please refer to Salesforce Help at https://help.salesforce.com/articleView?id=flow_concepts_bulkification.htm&type=5.

Limits and considerations

Before closing this chapter, please take note of some of the limits that flows have (as of the Winter 2020 release – some depend on your Salesforce edition):

• Max number of paused/waiting flows: 30,000-50,000.
• Max UI flows per monthly executions: 2,000-20,000,000.
• Max non-UI flows per monthly executions: 10,000,000-10,000,000,000.
• Versions per flow: 50.
• Total flows: 5-4,000 per flow type.
• When a flow is added to a Lightning page, don’t add an action (such as a record edit) before the first screen element; this will help you avoid unwanted actions being performed without the user actually being aware of them.
• When using change sets or the metadata API, a flow is deployed in an inactive state (and users can’t run it), so remember to activate flows if a Lightning page contains a flow after its deployment.
• When a flow is used within a Lightning page, the following variable types are not supported: collection, record, and record collection. Each component only supports the input variables that are manually entered. The text input accepts a maximum of 4,000 characters.

Take a look at Salesforce Help at https://help.salesforce.com/articleView?id=flow_considerations.htm&type=5 to find out more about the limits of flows, as well as what to take into consideration.