By Jeff Grosse (@CRMFYI), salesforce consultant
I’m beginning to think that one of the least explored sections of the Salesforce Setup menu is the section labeled “Flow”. The more I talk to people about it, the more I get curious responses saying, “I know it’s out there, but I have never tried it.” Flow is a somewhat hidden gem in the administrator and developer’s tool belt. The time to check out how it could be relevant to your organization is not when you find spare time; the time is now.
Flow, also known as Visual Flow, is a tool for collecting, processing and updating information in Salesforce based on business processes. It can be used in the standard Salesforce app your users are familiar with or deployed to a Salesforce portal or public website. If you’ve ever drawn a business process in a tool like Visio, designing it in Flow is very similar. It is easy enough that you don’t have to be a developer to use it, but it has the capability to use code if you want to expand your Flow to other apps or even reuse Apex code already available in Salesforce.
As a “business problem solver”, I bring my own sense of experience, expertise, and understanding to each project I work on. One of the beautiful things I like about being a consultant and working with many different companies, and teams is hearing how the experiences of others lead to solution ideas. It’s not like one person will ever have all the right answers, and in fact, with software development, there is always another way to do things which may just beat out the current idea and accelerate business further. Flow can do just that. It can augment or replace some standard Salesforce workflow. It can simplify processes, it can enforce business rules, and it can expand the horizons of what you thought you could do inside Salesforce. That’s why you need to check it out.
A brief history of Flow
Flow began as a way to visualize customer interactions and enable better decision management support for businesses. Since processes have a natural business flow to them, a team of software developers from the UK got together to improve the way those interactions take place. This team formed a company called Informavores which would be later acquired by Salesforce in late 2009. By bridging the gaps between various systems with a visual process diagram and allow process to change data in those systems, business integrations could not only be shown on paper, they could be measured by how often individual process paths were used provide facts gain insight to business. While Flow used to require a separate desktop app to design a Flow, you can now do it natively in your browser. While Flow used to look a bit different than “standard Salesforce”, it can now look like what your users are already familiar with in Salesforce or even be embedded in a Visualforce page for a completely custom look.
What can Flow do?
To understand what Flow can do both for Salesforce users and for customers, it is important to understand a few of the components of Flow.
- Screen – You can create screens to present or gather data which are, in essence, the steps to your process
- Decision – These are branches of your Flow that use data inputs and business logic to move the user to the next logical step in the process
- Assignment – Depending on input and business processes, data variables may need to be set or reset and assignments ensure the right data is stored to support the business process
- Data – At various times in a business process, you may need to look for a record or value in Salesforce. You may also need to create, update, or potentially even delete a record in Salesforce and that’s when you need the Data component.
- Apex – You can access any Apex code used by other processes in Salesforce or create new code specific to your Flow
- Flow – Reuse standard flows inside much more complex ones. Any flow can be saved and referenced inside other flows so you don’t have to recreate your past work to make use of it
What I did with it
The reason for my recent interest in Flow had to do with a customer project that I was on. We needed to guide sales reps to creating the right kind of activity records in Salesforce based on what type of event it was, the significance of that event, when it was done, and if other people were involved in that event. The answer to some of those questions would determine whether a standard Salesforce Task or a custom object record called a Call Plan would need to be created. Also from that, we needed to guide the user to the right status, target date and completed date for the activity. Finally, we needed to ensure that any activity logged was associated to a Contact from that specific Account. Here is what we did.
We used a new custom button from the Account record to begin the Flow. That button passed in the Account ID and Account Name which were stored as variables in the Flow. Using that Account ID, our Contact picklist was populated only with Contacts from the Account from which we launched the Flow. (That feature is called a Dynamic Lookup) We also used a radio button selector to know if the activity was in the Past or if it was for the Future. Lastly, we used a picklist to determine the Type of activity we were recording.
Based on responses, we determined which route the user would follow and whether a Task or a Call Plan would be created. Then we asked for either the Target Date or Completed Date for the activity based on their previous responses. Using Assignments, we then set the Status for the record we’d later create. If the result of the activity was a Call Plan, we’d show them four or five fields that were optional to fill out. (Future Call Plans had four optional fields and Past Call Plans had 5 fields, but one, called “Call Result” was required)
With all the data provided, the Flow then goes to Salesforce and creates a new record. The final page the user sees tells them that the Call Plan or Task has been created and we present them with two URLs. We present one of them if they want to go to the Account from which they originally invoked the Flow from, and we present them a second one which they can go to either the Call Plan or the Task which they just created in the Flow. Different circumstances may mean that they want to go to one over the other so we give them a choice.
The bottom line is, I created a simple process, kicked off by one click, that guided the user through creating the right record, with the right values, and helped them land where they want to when the Flow is over. We reduced the need to think about what type of record to create. We didn’t write code, yet we made the experience match the process.
If you are now thinking about what you could do with Flow, that’s awesome. If you want a process to consider trying out Flow with, I’ve got a great one. Use Flow to simplify the internal Salesforce support case creation process. Your users don’t necessarily need to see all the fields of cases when they tell you they have a problem. Use Flow to intake these questions and issues using just the fields they need. Let them kick it off with just a button or a link. It’s a great place to start.