There are many different automation options when it comes to Salesforce, but none are quit as powerful as Flows. Unlike relatively straight forward ‘If/then’ logic provided to us via workflow rules and process builder, flows allow us to achieve complexity levels close to custom code through a GUI. In this article we are going to talk about the types of flows, some best practices around flows as well as so intermediate concepts that can set you up for success!
If you are new to flow, it may be intimidating and you may feel lost as where to begin. Flow is provided as an admin tool but you still need to have that engineering mindset because many of the concepts leveraged in flow are identical to custom code. Don’t let this scare you. Practice. Just practice. Start with simple flows and don’t be afraid to make mistakes. As you continue to grow your skill with flows your quality will grow as well.
As stated, Flows allow you to implement much more complex logic through the power of declarative tools or configuration. Given all the options that Salesforce provides us to automate things, it can be difficult to choose the right option sometimes. Luckily Salesforce has provided us with guidelines and when to use which.
When it comes to updating fields often times a simple if/then logical flow will get you there. However, sometimes we need multiple if/then statements to achieve the requirement so you may want to leverage process builder. When those two options aren’t enough you may want to leverage flow which can update any record (not necessarily one that started the process), prompt the user with screens, call apex classes, send emails, launch approval processes etc.
In my opinion Flow is really the future and the now of Salesforce declarative development. Salesforce has put a tremendous amount of resources into flow and they will continue to do so.
Lightning Flow : Includes tools for building, managing and running flow and processes.
Flow Builder : Point and click tool for builder flows
Flow : Application that automates business processes by collecting data and doing smething in salesforce or external System
Type Of Flow
Types of flows and where to use them (use cases provided)
- Screen flow
- Auto-launched flow
A screen flow is a way for admins to create a process guided through various screens with clicks not code. The general idea is to prompt a user with a window to input some values. Based on those values I can make a decision in my flow on where to take the user. These processes could be a sales process, customer support process, etc. A potential use case could be the creation of a new record.
Sometimes in Salesforce we have a tremendous amount of data that needs to be added to a record to be able to save. This puts us in a position where we have one giant top down form that requires a user to continue to scroll down and enter data. If I have validation rules or required fields then I have to go back up in that page to find out where it is and correct it. Not a great user experience. As opposed to having a giant top down form, I could put different segments of that data in screen box and prompt a user to hit ‘next’ until I get through all screens and ultimately click save. Since I can make decisions based on data in the flow I can choose how the record will end without having to show a bunch of validation rule errors.
By putting this type of record creation in a flow now I have the ability to repurpose it! This same flow could be used to just simply input data by a sales rep after their meeting or I could launch it from an incoming call! Having the data segments flow from beginning to end will allow my call center rep to have a smooth conversation with the end user by taking them through a logical flow of questions.
There are several different ways to launch a screen flow. You can launch them through a button click, you can call its URL to have it launched from some other process, or as I mentioned you can trigger them on an incoming call. the list goes on.
A guided screen flow can do many things for me. I can reduce the amount of validation rules I need for data entry. It provides me with a logical flow of data entry that can dynamically change based on the values inputted. A nice screen flow allows me to guide a user through a business process and avoid giant top to bottom screens.
Whereas a guided screen flow allows me to guide a user through a business process, an auto-launched flow allows me to perform complex processing on the backend without a user knowing. You can think of it like a process builder or workflow rule, but the complexity potential is much greater! An auto-launched flow is sometimes called a headless flow because there is no GUI that a user interacts with.
The flow can be invoked by another process, like process builder or you can call its URL directly. An auto-launched flow invoked from a process builder can be thought of as an Apex Trigger + Trigger handler. An apex trigger is custom code that is invoked on some type of data event (DML). It is a best practice to leave processing logic out of the trigger itself and instead call an apex class that handles the complex stuff. This is the same as a process builder + flow.
A process builder is invoked based on a DML event (create or update) for a specific object, then makes a decision based on conditional logic and then performs an action which could be sending data to a flow!! The potential is great and empowers an admin to do things they wouldn’t otherwise be able to do with just a workflow rule or process builder alone.
If you’re not already excited about flows and its potential, you should be! Salesforce has put a tremendous amount of effort and energy into flows. As of winter 18?? Salesforce completely redesigned and overhauled the ‘cloud flow designer’. The original flow designer interface was slow, old looking and not user friendly. It was the kind of user interface people wanted to avoid and made creating flows a painful process. The new cloud flow designer UI is much faster, extremely responsive and has a ton of great features.
Whether you have an auto-launch flow or a screen flow you can debug the flow directly in the cloud flow designer. The debugging wizard allows you test your flow without saving a new version / activating and it also takes in real data in your org! Say you have a flow that does something with account records. You can create some test data in your org, launch the flow debugger, feed in the account record id and boom you get your outcomes all right in there without having to leave the page.
You also have the ability to call a flow from another flow. Note, to invoke one flow from another they must be the same type. This means I cannot invoke an auto-launch flow from a guided screen flow or vice versa. I can only invoke a screen flow from another screen flow or an auto-launch flow from an auto-launch flow. The possibilities here are substantial. Since I have the ability to have a flow call another flow that means that I can separate sections of logic in my flow and keep each flow relatively simple. Now, this doesn’t mean that every logical step should be put into its own flow, but by deliberately separating various parts of your flow you have reusable logic that can be applied for the next use case. This allows you to avoid replicating the same logic from flow to flow.
|Date : Saturday, April 26, 2020 10:00 AM EST (7:30 PM IST )|
Where : Online
Speaker : Luigi Franciosi
Bookmarks our “Session in 2020” page for all upcoming and old sessions of 2020. Let us know which topic you want learn next in ApexHours.
Thanks ” Luigi Franciosi” for a great blog post and session.
Salesforce Apex Hours
5,919 total views, 17 views today