8 Things You Should Know about Salesforce Lightning Flows
7 min
If you have been around the Salesforce ecosystem for any amount of time, you are probably familiar with the “clicks not code” mantra, which is a catchy way of saying that declarative development tools are one of the most crucial tools for the future state of digital transformation projects. Salesforce has doubled down on this point of view over the last several releases via improvements to Flow Builder. At this point, it has become one of the most regular and versatile means for architects, developers, and administrators to deliver solutions quickly and sustainably to address complex business problems. Don’t find yourself designing the next implementation or enhancement without reviewing the following tips and tricks!
1. There is only one remaining use case for Process Builder or Workflow Rules
While this claim may be met with some level of controversy, what used to be an evaluation of what one tool could do vs. another is no more. Flows are now equipped with all the features that Process Builder offers, and then some. The only reason to use a Workflow Rule is if an integration with Salesforce requires the use of an outbound message, which is already becoming more of an alternative option rather than the leading integration technology itself.
You will come across those that suggest certain or simple requirements be addressed with the “less complex” methods, however the counterargument is more compelling: organize your entire suite of automation with a single tool and with a consistent framework, and your functionality will be easier to maintain than if it lived scattered throughout your instance of Salesforce. Before Save Record-Triggered Flows are more efficient than Process Builders and Workflows and grant the benefit of having first dibs in the order of execution during a CRUD transaction.
Another common argument against Flows is that Record-Triggered Flows do not support Subflows, making it difficult to organize and difficult to follow the single responsibility principle. See the section on Event-Triggered Flows for a closer look at how to optimize your Flow library!
2. There are still several things that Flows cannot do
Even with the significant improvements to Flows in the latest releases, there are a few key areas that are still lacking within the declarative UI. That said, the flexibility of using invocable methods called from Apex actions within the Flows allow developers to write very minimal, intentional lines of code to fill the gaps.
- Here are just a few examples of where Apex might be needed to augment Flow functionality:
- Dynamic sObject References – when you have logic that could be applied to more than one object in Salesforce, Flow will not allow you to query or perform database transactions without naming specific objects.
- SOQL Query with an IN Clause – Flows have incredibly useful Get Records elements which essentially perform SOQL queries and return records based on the criteria defined. Unfortunately, there is no declarative equivalent to the IN clause, so advanced queries require either some Apex or some creativity to achieve the desired outcome.
3. Show some love to the under-utilized Event-Triggered Flow
Perhaps the most neglected type of Flow, those triggered by Platform Events are also likely the most powerful and useful for organizing your automation suite in a way that follows the single responsibility principle of development and decouples your automation to reduce the odds of bumping up against those pesky governor limits. While you may have heard of Platform Events as Salesforce’s impressive event-driven integration mechanism, think “declarative @future method” for their application internally to a single Salesforce org.
- Take the following steps to implement Platform Events within your automation suite:
- Go to Setup > Platform Events and define a new Platform Event
- Define a new Text(18) field on the Platform Event for the ID of the record that triggers the event
- Go to Setup > Flows and create a new Record-Triggered Flow that creates a record of the Platform Event when certain criteria are met, passing the Record ID as the parameter
- Create a separate Event-Triggered Flow that queries for the full Record based on the ID that was passed in and subsequently performs the appropriate business logic
- Keep in mind the following considerations when designing your automation and leveraging Platform Events:
- Platform Events are not immune to limit governance – as such, it is not recommended to fire every time a record is edited and meets criteria (see example below, only when the field Type is changed is when the corresponding event fires, not every time Type equals a certain value)
- As a “declarative @future method”, database commits take place in a separate transaction a split second after the initial operation, meaning that if an update is expected on the current screen, another method may allow for a better user experience that does not require a page refresh
- An error that takes place within the Event-Triggered Flow will not prevent saving the initial operation, which means error handling and/or retrying is increasingly important
4. Enhance the User Experience with Next Best Action
Another way to extend your automation suite is with the Einstein Next Best Action feature, which allows you to take the Flows you have built and recommend them to your users based on the context of the record they are viewing.
For instance, display an option to your users to extend an offer for a temporarily reduced rate for a customer that has submitted a “Cancel My Subscription” case. If accepted, Flow logic can control the creation of the corresponding Opportunity record, update the monthly rate, and schedule an action to increase the rate back to normal after the promotional period expires.
- To implement Next Best Action, follow these steps:
- Create a Flow to perform the required actions
- Create a Recommendation record that references the Flow
- Create a Next Best Action Strategy to decide when to suggest the action
- Add the Next Best Action lightning component to the page
5. Auto layout can sometimes conflict with the graceful handling of errors
One of the more recent features introduced to Flows, auto layout has quickly become a beloved way to increase readability and ease of troubleshooting more complex Flows. Perhaps the biggest challenge with auto layout, however, is that error handling has become an afterthought at the risk of defacing a pristine piece of automation.
- And here is how:
- A fault path is just that – a singular path that cannot retry or continue the Flow as is possible outside of auto layout. On occasion, it is perfectly reasonable and acceptable to either return to an earlier element or to continue through the rest of the Flow logic after an error.
- In some cases, it is useful to direct multiple fault paths to a single Flow element, which cannot be done in auto layout. This can result in duplicative elements to achieve similar functionality, which equates to additional overhead and technical debt.
6. Pink squares can never go inside loop elements
One of the most common mistakes that Flow builders make is when a pink element (Get, Create, Update, Delete) makes its way inside of a loop element, before the “After Last” piece of logic.
- While it may seem innocent and efficient on the surface, there are several implications:
- You increase the odds of hitting the limit of 100 SOQL queries (which is a 200 query limit with Platform Events!)
- You increase the odds of hitting the limit of 150 DML statements
- You increase the odds of hitting the limit of 2000 Flow elements at run time
- You increase the odds of hitting the CPU processing time limit
As you can see, all it takes is a little bit of volume or complexity to end up with an unreliable piece of functionality. In order to follow the sustainable and scalable recommended practices, utilize record collection variables to store the records to be created or updated, and then perform the operation in a single statement on the collection after the loop rather than on each individual record within the loop.
7. Check your email
Do not forget to set yourself as a recipient of any error emails generated by your Flow! They are the single most useful tool in debugging unexpected issues as they point to the specific element that caused the issue, along with a detailed error message.
8. Consider your successor
If you have ever written a Flow, you have likely also reviewed, troubleshot, or enhanced a Flow configured by another builder. And if you have done the latter, you have also probably thought to yourself, “What in the world was this person thinking!”
Use those moments to fuel your own motivation to follow proper Flow etiquette – use verbose naming conventions and descriptions, use consistent true/false descriptors in decision elements, and clean up after yourself – delete the unused variables and elements that might be floating around and leading to additional confusion for the next person to lay eyes on your handiwork.
With all that Salesforce’s Lightning Flows have to offer, you are sure to have a fun time working through your next automation requirement.
