Flow is one of the quickest developing Salesforce items. Some time prior it began with Screen Flow and Autolauched Flow and presently there are five choices. It includes something dependent on Process Builder to an apparatus that can be utilized autonomously which even has the usefulness that Process Builder doesn't have. As per Salesforce, they have no designs to supplant Process Builder with Flow, however as I would see it resembles the drawn-out objective, which is additionally why getting to know this product is vital. How about we plunge into the different stream types so you know how every one of them helps increment the efficiency of your example.
1. Screen Flow
This is my first stream type as you can make countless potential outcomes with Screen Flow. You can direct your clients through a convoluted interaction, request input from them, or essentially post messages or notes. Contemplate the auto-bots that you frequently see on various sites, and that is the thing you can accomplish with Screen Flows. The enchantment is truly at the Screen part. When you know about that, you can make loads of fun arrangements. The walkthrough of the Screen part can be found in this article.
Notwithstanding, note that Screen Flow is one of the two kinds that depend on one more point of interaction to send off the stream. This implies, that after you finish the stream, you really want to either make an activity, a button, put the stream inside a Process, or put it on the Lightning Page.
2. Autolaunched Flow – The Foundation of Other Flow Types
This kind of should be simple to understand. You simply tell the machine what to perform without interacting with the users. No one would know what had been triggered and done unless they looked at the system logs. However, this will serve as the framework for the introduction of new flow types.
You have Screen and Auto launched types in the early stages of Flow, both of which rely on other interfaces to fire the flows. If you want to present a screen for users to submit their names once an account is created, for example, you'll design a Screen flow first, then a Process Builder process that triggers this flow whenever an account is created. This takes some time, but it's necessary because Process Builder can't connect with your users.
Is it, however, still appropriate for an autolaunched flow? Assume that when the account's annual revenue reaches $1 billion, you wish to change the account's rating to Hot. To alter account rating with Flow, you'd first design an autolaunched flow, then embed it in a process that should be triggered when annual revenue changes. Do you see what's going on here? Why do we need to build a single flow and process when everything can be done in one?
The Record-Triggered and Scheduled-Triggered flows were created as a result. They make it possible to fire flows without referring them from a process.
Don't forget to check out: How to Trigger the Lead Assignment Rule from Flow Builder
3. Record-Triggered Flow
This is, in my opinion, the most difficult type because of the flexibility! It's so versatile that you can create 11 distinct scenarios with it! Let's take a look at them one by one.
- A record is created
- A record is updated
- A record is created or updated
- A record is deleted
You may be able to avoid creating triggers in some situations by using record-triggered flows. Like When an item is eliminated, the flow begins. If you're working on your admin certificate, don't forget to pay attention to the order of execution. According to Salesforce, A record-triggered flow can update a Salesforce record 10 times faster than a manual update.
4. Schedule-Triggered Flow
You can plan your flows to run at a specific interval and at a specific time, allowing you to automate recurring tasks. (For example, cleaning up old data, sending monthly emails, and so on.)
The key distinction is the "Set Schedule" option. You can set the start date, start time, and frequency when you select this option. It should be simple to set this up, so give it a shot if you have any procedures that are currently handled manually in your instance!
- Daily or
You might be able to avoid utilizing Apex Schedule Jobs by using Batch Apex if you use schedule-triggered Flows. You may now address repetitive business requirements without having to use the platform's development capabilities. For example, delivering birthday greetings to customers who have birthdays on that day every morning, or closing cases that have been in a given status for a certain number of days every night.
Check out another amazing blog by Shivam here: Object Level Security in Salesforce | The Salesforce Security Guide
5. Platform Event-Triggered Flow
You can conduct all of your automation in one location using platform event-triggered flows. When a platform event message is received, users can initiate a Flow. When a Flow is triggered by a platform event message, users have access to all accessible records, unlike Process Builder. Process Builder and Flow Builder were formerly necessary for platform event–driven automation.
Platform Events are something that developers, but not necessarily administrators, will pay attention to. Platform events, to put it simply, are communications that various systems send to each other or to themselves. I've never used this sort of flow as an administrator, and I doubt I ever will so see the developer's documentation for additional information.
Platform Event Considerations:
- We can't ensure which of the platform event-triggered flows, halted flow interviews, and processes each event message first if they're all subscribing to the same platform event.
- A flow can receive a batch of event messages at a time, up to a maximum of 2,000.
- The Automated Process user has debug logs for platform event-triggered flows and resumed flow interviews.