In the past few years, Salesforce has dumped time, energy and resources into perfecting their Lightning Flow feature, a front and backend process management tool created for Salesforce admins to optimize their process-building workflows. And in order to take advantage of all Lightning Flow features benefits, you have to stay in the know about all of their newest enhancements.
But to embrace the enhancements means, paradoxically, you need to know the history of Lightning Flow.
So here’s a thirty-second history lesson. Historically speaking, Lightning Flow still required heavy writing of Apex code (duh duh duhhhh) to accomplish complex task building.
Maybe that was closer to 15 seconds…🤔
All the same, flash forward to the present, and that same dependency system admins used to have on developers to write Apex code has lessened dramatically.
Here are three tips Salesforce configurators should use to accomplish tasks that were once only achievable through custom Apex coding:
Non-developers used to be limited in their ability to schedule workflows because scheduling is typically restricted to time-based workflow actions set in and by Workflow Rules and Process Builder. However, in Salesforce’s Winter ‘20 release, they updated time-based workflows to function in Lightning Flow as well (phew, saved by the bell). This means admins can build complex, scheduled automation on large sets of records without needing to write Apex code or worry about breaking time-based workflow limitations in Workflow Rules and Process Builder.
Let’s see what this looks like when we put this into action. Let’s also assume we have a use case requiring us to update all Opportunities at the end of each week to “Closed-Won” that are:
You’re presented with two options. You can either risk writing a botched assortment of Apex code to get the job done or you can use what we just learned about scheduled Workflows to meet this requirement.
You can do this simply by creating a scheduled Flow to kick off at 5PM every Friday evening. Additionally, you’ll need to indicate a desired start date and time—recurring on Fridays at 5PM— by adding a “Start” Flow element. You’ll also need to select a frequency to indicate that it’s recurring, so in this case you’d select “Weekly.”
Once that’s completed, query only the Opportunity records in the “Agreement” Stage.
Pro Tip: If you’re concerned about hitting system limits related to the number of records being processed, then decreasing your Flow run time by decreasing the number of Opportunities it digests is an easy way to reduce your dataset.
Next, you need to query the Opportunity Products assigned to each Opportunity before deciding whether to close the Opportunity. Friendly reminder, in this example, you only want to close the Opportunity if it contains “Product X.” You can do this by adding a “GetRecords” Flow element to query Opportunity Product objects for “Product X.” See how to edit your “GetRecords” Flow element below 👇:
Then add a “Decision” Flow element to either ignore the Opportunity or mark it as “Closed-Won”.
You’re almost done. As the second-to-last step of your Flow, you’ll need to add an “Update” Flow element in order to update all Opportunities to “Closed-Won” that are in the “Agreement” stage and contain “Product X” as an Opportunity Product.
Now, activate your Flow.
It will start to run based on your predefined start date and time. Per the example, your Flow should look something like this once completed:
Working on optimizing your Salesforce org? Boost operational efficiency with these 5 essential Salesforce integrations.
Salesforce automations–whether they run via Apex code, Workflow, Process Builder or Flow–run in either “system context” or “user context.” Contexts, in the Salesforce world, are used to define an automation’s permissions and privileges for an individual user, a group of users or an entire Salesforce org.
There are two different types of contexts. Let’s breakdown what they are and how they impact your Flow building 👇:
#1 System Context | Defines scenarios in which an automation ignores the permissions and privileges of the current running user.
#2 User Context | Defines scenarios in which an automation respects the permissions and privileges of the current running user.
For each context type, the permissions and privileges considered are profiles, permission sets, sharing rules, org-wide defaults, or any other concept that grants or restricts access to objects, fields, or records.
Historically, Flows have run on User Context. But this has caused a multitude of issues. For instance, if a user doesn’t have access to a specific field but a Flow runs and tries to update that specific field based on an action that user took, the Flow will error out and the update will fail (I’m with you—it’s super frustrating!). This ultimately made the vast majority of Flows unreliable for tackling any backend tasks, as the running user needed to have access to the field, object, and specific record being updated.
The good news? Salesforce has recently opened up the option for you to actually specify which context you want your Flow to run. There are three types of context options under Advanced settings when determining how you want to run your low. These three options can be found under Advanced Settings in the Lightning Flow Builder tool:
Here’s a breakdown of what each option represents 👇:
#1 | User or System Context – Depends on how Flow is launched (Generally Available, where all customers can use this functionality in production today.)
Example: Auto-Launched Flows launched from the Process Builder tool are defaulted into “System Context with Sharing” while Screen Flows launched from actions will default into “User Context.”
#2 | System Context with Sharing – Enforces Record-Level access (Generally Available)
Example: If you have a Flow that updates a specific field on the Account object for a large set of Accounts on a weekly basis. In this scenario, Salesforce doesn’t care if the running user has “Edit” access to the Account Object or even the specific field being updated. However, if the user doesn’t have access to a specific account record due to the sharing model (role hierarchy, org-wide defaults), it will not be updated when the Flow runs.
#3 | System Context Without Sharing – Where all users are able to access all data (available with the Summer ‘20 Release)
Example: Say you want to implement an auto-launched Flow in “System Context Without Sharing” that creates a Custom Object Record whenever a user closes an Opportunity as “Closed-Won”. Well, you no longer need to worry about your sales reps having access to the Custom Object or the individual fields on that Object since you’re running in system context.
This flexibility lends a lot of power back to Flow-lovers. You can now safely design auto-launched Flows to carry out repetitive tasks without worrying about the running user’s actual permissions.
Traditionally, Flows–whether they’re Screen Flows or Auto-Launched Flows–have needed some sort of interaction to start them. Screen Flows have required some sort of user interaction, like a user clicking a button. On the other hand, auto-launched Flows have always depended on some other Salesforce tool to call them to run, like a Process Builder or Apex class. A lot of users might find this both annoying and redundant because most other Salesforce automation tools don’t rely on something else in Salesforce to call them to start. For instance, Process Builders and Workflow Rules, contain both the criteria to launch them and the actual process in the same Flow Builder tool. Flow has been disjointed in this regard and relies on other tools to run.
Now, with the new Summer ‘20 release, auto-launched Flows can truly live (and start) on their own and become triggered from the Flow itself.
This is where that happens. 👇
With the new “Configure Trigger” screen, you can set the Flow to trigger under one of these three conditions:
If you are familiar with other Salesforce automation tools, these options may be all too familiar for you. And on top of this, you can now specify when to run the Flow in terms of the order of operations. This idea mirrors the “before” and “after” trigger concept in Apex coding, which runs triggers either before or after a record is committed to a database.
Now, in Lightning Flow Builder, you’re able to set the Flow to run in two different contexts based on how you want to subsequently update data at the end of your Flow:
The ability to specify this context helps you become more accurate in staging your Flow triggers and associated actions. Context also reduces the possibility of issues like recursion (executing the same task multiple times) or calling unwanted automation like Apex triggers or other Flows. Finally, context also vastly improves the debugging process, as Flow creators will now know exactly where each Flow fires in the order of operations.
For more recommendations on how to build good Salesforce Lightning Flow habits, check out new and improved updates in Salesforce’s Summer 2020 Release notes.
Gray is a 9x Salesforce certified Solution Architect at Canpango. Gray has over five years of experience in designing and building Salesforce solutions for enterprise-level organizations like Johnson & Johnson and IBM. Additionally, he has developed solutions for small and mid-size businesses across the healthcare, life sciences, high tech, agriculture and manufacturing industries. Gray takes pride in designing Salesforce orgs that withstand the test of time and can flexibly scale with his client’s future business requirements.
Stay in the know with insights and updates delivered directly to your inbox.