Learning Salesforce Flows – Part 3 – Understanding the Types of Salesforce Flows and Best Practices

Introduction:

Welcome to the latest installment of our “Learning Salesforce Flows” series. In this blog post, we’ll be taking a comprehensive look at Salesforce Flows, with a particular focus on the various types of Flows and best practices for creating effective automation.

Types of Flows in Salesforce

The two primary types of Salesforce Flows – Screen Flows and Autolaunched flows, which people commonly use, are shown in the image below.

Types of Flows

Screen Flows:

The most commonly used type of Flows, Screen Flows guide a user through a set of screens to collect data. It includes screens, local actions, steps, choices, or dynamic choices. Screen flows are ideal for collecting information from users and guiding them through a process.

Screen flows can be distributed through various means, including flow actions, Lightning pages, Experience Builder pages, custom Aura components, custom Lightning web components, custom buttons or custom links, Flow Orchestration, web tabs, direct flow URLs, Visualforce pages, Lightning Out, and Embedded Service deployments.

Pros:

Screen flows allow you to create interactive experiences for users.
They provide a visual interface to guide users through complex processes.
It is possible to customize screen flows to align with your brand and meet your user requirements.

Cons:

Screen flows are not suitable for long-running processes.
They don’t support pause elements, which may limit their use cases.

Autolaunched Flows:

Auto-launched flows are a type of automation in Salesforce that can be triggered by an event such as a record being created, updated, or deleted. These flows do not require user interaction and can be used to perform a variety of actions such as creating or updating records, sending emails, or posting to Chatter.

Lets see below several types of auto-launched flows:

1. Record-Triggered Flow:

This type of flow is triggered when a record is created or updated. It can be used to automate processes such as updating related records or sending notifications to users. There are two types of record-triggered flows that can be used to perform actions before (Fast Field and Actions) or after a record (Actions and Related Records) is saved.

Pros:

By using “Before” flows, you can conduct calculations or validation checks before saving the record. This can aid in maintaining data quality and consistency.
“After” flows can be utilized to execute further updates or send notifications based on the result of the save operation. This can streamline business processes and enhance efficiency.
Both “Before” and “After” flows can be significantly customized to handle intricate business logic and relationships between records.
Record-triggered flows are generally more flexible and powerful than traditional workflow rules or process builders, as they can handle more complex logic and can update related records.

Cons:

If not properly designed and optimized, record-triggered flows can have an impact on the performance of your Salesforce org. For example, if you have a large number of records being updated at once, the flow could cause a significant delay in processing time.
In the event that certain validation rules or criteria are not satisfied, “Before” flows can prevent the save operation from taking place, potentially causing frustration or confusion for users.
“After” flows may not execute in certain scenarios, such as when a record is deleted. This can result in data inconsistencies.
Record-triggered flows can be more complex to set up and manage than traditional workflow rules or process builders, especially if you are not familiar with flow design.

2. Schedule-Triggered Flow:

This flow type runs only from a schedule and doesn’t support user interaction, screens, local actions, choices, or choice sets. It’s ideal for processes that need to run on a regular basis, such as data updates or clean-ups.

Pros:

Schedule-triggered flows can be used for processes that need to run on a regular basis.
They can be used for data updates or clean-ups.

Cons:

They are not suitable for user interaction or front end processes.
They may require additional setup to trigger them, such as custom Apex classes or REST API.

3. Autolaunched Flow with No Flow Trigger:

This flow type doesn’t require user interaction and doesn’t have screens, local actions, choices, or choice sets. It’s ideal for backend processes, such as data manipulation, integrations, and API calls.

Pros:

These flows can be used for backend processes, such as data manipulation and integrations.
They can be triggered by other processes or through custom Apex classes, REST API, Flow Orchestration, web tabs, custom buttons or custom links, and Visualforce pages.

Cons:

These flows are not suitable for user interaction or frontend processes.
They may require additional setup to trigger them, such as custom Apex classes or REST API.

4. Platform Event-Triggered Flow:

This type of flow is triggered by a platform event. Platform events are custom notifications that can be created in Salesforce to notify external systems or processes when certain events occur in Salesforce.

Pros:

Platform event-triggered flows can help you automate processes based on notifications from external systems or applications.
They can help you integrate Salesforce with other systems or applications.
They can help reduce processing time and handle complex business logic.

Cons:

They can be more complex to set up and manage than other automation tools.
They may require additional development effort to integrate with external systems.
They can cause performance issues if not designed and optimized properly.

Flow Best Practices: Everything You Need to Know

If you’re planning to build and distribute flows, it’s essential to understand best practices. By following these guidelines, you can avoid common mistakes and ensure that your flows work smoothly and efficiently.

Here are some flow best practices to keep in mind:

Plan your flow before you start building – Before you start building your flow, write or draw out all the details of your business process. This way, you’ll have a clear idea of what information you need, where you’re getting that information from, and what logic and actions to perform. This can make building your flow much easier and more efficient.
Build your flows in a test environment – Building your flows in a sandbox or Developer Edition org can help you avoid accidentally changing records in your company’s production org. This way, you can enter fake data and test various permutations of your flow without worrying about changing or deleting data that your users actually need.
Don’t hard-code Salesforce IDs – Ds are org-specific, so don’t hard-code new or existing IDs. Instead, let Salesforce create the IDs, and pass them into variables when the flow starts. You can do this using merge fields in URL parameters or by using a Get Records element.
Wait until the end of the flow to make changes to the database – To avoid hitting flow limits, we recommend bunching all your database changes together at the end of the flow, whether those changes create, update, or delete records. And avoid making the changes in a loop path.
Control when running users can navigate backward – If the flow commits changes to the database or performs actions between two screens, don’t let users navigate from the later screen to the previous screen. Otherwise, the flow can make duplicate changes to the database.
Provide an error handler – Sometimes a flow doesn’t perform an operation that you configured it to do. By default, the flow shows an error message to the user and emails the admin who created the flow. However, you can control that behavior. Customize What Happens When a Flow Fails for more information and recommendations.
Save early and often – Salesforce doesn’t save your changes automatically, so it’s up to you to save your work. Save as often as possible, so that you don’t accidentally lose a few hours’ worth of work.
Restrict data access via profiles and permission sets – Make sure that only the right flow users can access data at the right time. To restrict access to enabled profiles or permission sets, edit the access for a flow from the Flows list view.
Avoid mixing DML operations – When a flow must respect user permissions for some actions and ignore user permissions for other actions, you can use the Subflow element.
Control data access with the Subflow element – To respect user permissions for actions, you create a flow that runs in user context. To ignore user permissions such as object permissions and field-level access for other actions, you create a separate flow that runs in system context. To put it all together, you can use the Subflow element in the flow that runs in user context to launch the flow that runs in system context.
Test as many permutations of your flow as you can – It’s important to test your work before distributing the flow to your users, especially if your flow uses branching or other complex logic. Make sure that you test as many possibilities as you can think of before you distribute the flow to your users.
Avoid accessing external objects after DML operations in a transaction – If Salesforce creates, updates, or deletes data in your org and then accesses external data in the same transaction, an error occurs. To avoid this issue, we recommend using a separate transaction to access data in an external system.
Avoid mixing DML operations – A single transaction can’t mix DML operations on objects (such as Account), setup objects (such as User Role). For example, if Salesforce updates an account and a user role in a single transaction, an error occurs. We recommend using a separate transaction for the same.

Here is an good article that you can see for further learning – https://admin.salesforce.com/blog/2021/the-ultimate-guide-to-flow-best-practices-and-standards

Reference Links –

Flow Types

For more helpful articles please visit – https://thesalesforcedev.wordpress.com/