Hundreds. This is the number of times you have probably heard about all of the amazing things that the Cloud Flow Designer (formerly Visual Workflow) can do. But for the non-technical, declarative developers like myself, my mind hasn’t properly wrapped itself around the complexities of the tool and as a result, I had nearly given up on it.

Until recently.

There has been a lingering problem at ReadyTalk that I have been wanting to solve for some time but traditionally, the solution would require code. We have a full team of developers that could probably fix this problem easily, but I wanted to figure it out on my own.

I’ve conquered this problem using Cloud Flow Designer, I’ve celebrated (just like the kid in this picture – literally) and now I want to share the results with you.

While I try not to post org-specific “how-to” posts on Admin Hero, I think that the solution is something that can be easily modified and applied to similar scenarios. Plus, I want you to see that this isn’t as scary as it may seem.

Before we begin, you should know that this is not a comprehensive post on Cloud Flow Designer. I am not experienced in the application enough to speak to the specifics. Instead, I simply want to share the problem I was faced with and the solution that I was able to hack together using the Cloud Flow Designer.

In addition, I am going to provide you with an overview of the solution which means that I will not outline every single step or explain every element of the solution. That’s where you’ll need to do some additional research!

Okay, let’s go!

The Thorn In My Side

Before we get into the details, let me explain the business problem I am trying to solve.

Sometimes, ReadyTalk customers request that we opt all users from all emails with the exception of a designated “Account Admin.”

In the past, this has been managed by doing several mass updates on the contact records to opt everyone out of emails. While easy to process, it has turned into a nightmare from a data integrity perspective and we really wanted to find a way to automate this process.

Here are the requirements I was trying to meet:

• On the Account record, include a checkbox called All Account Email Opt-Out which when checked, would automatically opt-out all contacts associated with that account except for those contacts who have the Account Admin checkbox checked.
• When the All Account Email Op-Out checkbox moves from checked to unchecked (True to False), opt-in all Active contacts under that account into two of our mailing lists.

While a workflow rule will update the appropriate fields on the Contact record, it requires that the contact record is edited before the changes are applied. With potentially hundreds of contacts per account, this wasn’t a feasible solution.

Code was an obvious solution, but I wanted to try to do this using declarative technology, so I turned to Process Builder. Using only Process Builder, I was able to create a similar flow, but again, the contact record had to be modified and saved in order for the process to take place and the updates to work.

That is when I decided to focus on the Cloud Flow Designer (which we will call Flow for short).

Flow vs Process Builder vs Workflow Rules

Before we get into the details of Flow and super simple solution, let’s talk about Flow and Process Builder. I often see questions throughout the community and on Twitter asking about the difference between Flow, Process Builder, and Workflow Rules.

This table outlines the benefits and features of each (including Approvals) which outlines the differences nicely. This table and additional information related to the table can be found by clicking here.

Notice that Process Builder is similar to Workflows in that they work only when a record is changed. Based on my requirements, the problem couldn’t be solved using only Process Builder or only Workflows.

However, Flow (Visual Workflow in the table) starts when a user clicks a button or link, when a user accesses a custom tab, when a process starts, or when Apex is called. In addition, it can do everything on this list except send an outbound message without code. This is exactly what I need in order to complete this request.

Some Comments on Flow

I’ve gone through the Visual Workflow guide and was able to successfully create a working flow. But, the problem with all of those workbooks is that they don’t tell you why you are taking those specific actions, they just explain how. So, while I built a flow, I had no idea how to use the elements to recreate it.

So, I began from scratch – learning Flow as I went. If you aren’t familiar with Flow, I would encourage you to go through the workbook or read the help documentation as a baseline. Get familiar with the application and the UI before you get started.

Recently, some new features were released called Headless Flow and Flow Trigger which allowed any flow to be triggered without requiring a screen to be presented to the user. Essentially, Flows can now operate similarly to Workflow Rules; quietly in the background without no one knowing. Basically, you can use Apex or a Workflow Rule or Process Builder to trigger a flow when the specified conditions are met.

Finding this information was exactly what I needed to know in order to provide a solution that met the requirements my company was looking for.

The Beautiful, Code-Free Solution

The solution to the above requirements took some time to figure out, but I ended up creating the following:

1. Two Flows; one that opts-out the contacts on an account and the other that opts them back in via field updates.
2. Two Workflow Rules which evaluates that status of the All Account Mass Email Opt Out field on the contact record and triggers the Flow Action for the appropriate flow.

I am going to show you the solution to the opt-out portion of the request. The opt-in process is a clone of the following functionality with an update to the criteria and fields which will be updated.

Building the Flow

Building this flow was no easy task. I spent a full day experimenting with the different Flow elements, reading one of Brian Kwong’s blog posts on how to create a headless flow and I was truly stumped. But, I eventually go it figured out and realized that I was over complicating the entire process! Here’s the flow I ended up with:

Yup! That’s it! A single action. No lookups, no decision trees. Just one step.

Notice that it is a Record Update step which means that the only thing this flow is going to do is update the appropriate contact records once triggered. This next screenshot shows the details of this step.

Let me walk you through this screen really quick. The numbers on the screenshot align with the numbers below.

1. This step has been provided with a name. This is the same process as creating a custom field or object and giving it a name.
2. Contact is the object that I want to update in this step, so I’ve chosen it from the list of available objects.
3. Filter criteria allow me to select which records will be updated from that object. In this case, I want to update Contact records related to a specific account (AccountID) and where the Account Admin field does not equal true.
4. This section indicates what updates will take place. I’ve decided to update the standard Email Opt Out field so that it is equal to True.

So within this one step we’ve indicated the exact records we want to update and what the update should include.

Now that the update action has been created via a flow, we still need to create a way to trigger the flow so that it processes records. That’s where our workflow rule comes into play.

Building the Workflow Rule

UPDATE: The Process Builder has superseded flow trigger workflow actions, formerly available in a pilot program. Organizations that are using flow trigger workflow actions can continue to create and edit them, but flow trigger workflow actions aren’t available for new organizations.

This part is easy. I’ve created a standard workflow rule on the Account object with the following formula criteria:

AND( 
ISCHANGED( All_Account_Mass_Email_Opt_Out__c ), 
All_Account_Mass_Email_Opt_Out__c = TRUE)

When the All Account Mass Email Opt Out field on the Account has changed and it is now equal to True, the workflow will activate the workflow action.

The Workflow Action added to this Workflow is the new Flow Trigger action. This action allows you to select a flow you want to trigger and map values from the Workflow object into Flow variables. Here’s my Flow Trigger action.

A name was provided to this action, and I selected the flow name from the picklist provided. After checking the Set Flow Variables box, a picklist appears where any variables created in the Flow appear. I’ve selected my AccountID variable and selected the value I want to pass to this variable when the workflow rule fires.

So, what happens now is the workflow is triggered when the criteria are true, and it will pass the AccountID into the flow created and execute the update actions outlined in the Flow. WOWZERS!

What once required code, I’ve done with a Workflow and a single-step Flow!

Now, users can check the All Account Mass Email Opt-Out checkbox on the account and automatically, all contacts are magically opted out of emails!

Parting Thoughts & Observations

I’ll be honest. I have been intimidated by Flow for a while. It took me nearly two full days to dig into Flow to solve this problem using Flow, but I figured it out. I leveraged the community and various resources to connect the dots. And it feels good! I’m glad it took me 5 revisions and endless testing!

The feeling of struggling, then accomplishing is like no other. Don’t be intimidated by Salesforce. It may be big and seemingly complex, but you can do this!

Get outside of your comfort zone and experiment with these tools. You’ll be surprised at what you’ll learn and feel great with the results.