For over 100 cities across the world, last week was Lightning Week, where user groups shared information and demonstrations on the four new features introduced with Salesforce1 Lightning: Components, Connect, App Builder and Process Builder.
But just how new is that last one? Well, the Process Builder UI, with its flow-chart style of layout, is certainly new. But what you may not know is that, under the hood, all processes built using the Process Builder are actually flows running on the established Visual Workflow engine.
But why is this important? We wanted to explain what this fact means for you and how you can make the most of it.
The first reason you’ll want to know that processes are flows is that this fact surfaces itself in two key areas of Salesforce. For a start, you’ll quickly find that any issues caused by processes not working correctly or hitting a problem at runtime result in a fairly generic ‘failed to trigger a flow’ error message. Knowing that it could be a process, rather than a fully-fledged flow, which caused this means you know where to look when troubleshooting the error.
The other area of the app where it helps to know that processes are flows is when checking pending scheduled actions. With workflow rules, we could look under Setup > Monitor > Time-Based Workflow to find queued workflow actions. But scheduled actions from processes don’t appear there (though maybe they should); instead you’ll find them alongside other pending flow actions at Setup > Create > Workflow & Approvals > Flows > Paused and Waiting Interviews.
The second reason that getting a handle on this process/flow relationship will be critical to your use of the Process Builder is that when migrating processes, either in a change set or a package, you do so by including the hidden flow components rather than anything named as a ‘process’.
But as well as being interesting to note for error-handling, action monitoring and metadata packaging, we wanted to explore how we could use this process/flow relationship to our advantage.
The most immediately striking possibility for me is this: Processes are easy to build, with a simple UI that anyone used to creating classic workflow rules will be able to learn very quickly. Yet Visual Workflow has been around for a few years but arguably hasn’t reached the same widespread level of use; it’s hugely powerful but there is something about the way it’s built that means it comes with a steeper learning curve. Maybe it’s the Flash UI, or perhaps it’s the more technical terminology (What on earth is an sObject? When would I use fault connector? How do I know whether I need a Record Lookup or a Fast Lookup?).
So why couldn’t we use the fact that processes are flows to our advantage? If we build a process that we understand fully, then if we were able to find the flow behind it then we could look at that to get an idea of how flows are constructed, what elements to use when, how those elements are connected, and how features like variables, decisions, sObjects and collections are used. This could be a great way of helping us overcome, or at least reduce the gradient of, that flow learning curve!
But wait, it’s not that simple, is it? It’s fine to know the theory that processes create flows, but if I navigate to Setup > Create > Workflow & Approvals > Flows, I can’t find them. So where are they hiding?
The first thing to realise is that the system is hiding them from you for a reason – we shouldn’t, or at least we may not, know processes as flows so more people would be confused by finding their processes appearing in the flow area than would be helped by it.
But there is a way of getting at them. We just need to find the hidden entrance.
To find that, we need to revisit something we mentioned earlier. Processes can be added to change sets by finding them under the Flow heading. And, as those of you used to building change sets will know, when browsing through components to add to a change set you can click the component’s name to be taken to its details in setup.
So let’s try that – start building a dummy change set, find your process under Flow and click the name. Bingo – we’re taken to a flow definition page. The secret door is open. We see the system-generated flow which powers our process.
(Note: Building change sets requires an org with a deployment connection established, so will not work in a developer org, but you could achieve the same thing by creating a package.)
Here, as an example, is the flow that sits behind a sample process which updates all contacts’ Business Phone fields when the parent account’s Phone value is changed:
We can see some decision elements help the flow to evaluate whether the account’s phone number has undergone a change and, if so, a Record Update helps us to update all child contacts in one step. From there, you can even click into the Record Update element to see how simply it’s defined.
By following each element and connector in the flow and comparing it to how we defined our process, we get a really useful booster in our learning of Visual Workflow. And all we needed to do was to know where to look for that secret door!
So there we have it – we now know not only why it’s important to realise that processes and flows are, at the heart of it, the same thing, but also how we can turn this relationship to our advantage. Go out there and conquer Process Builder, and the world of flow – with its vast riches and far-reaching power – will soon fall at your feet!
Update (12/06/15): Sadly, it seems that the trick of finding the shadow flow behind a process by going via change sets is no longer supported as of the Summer ’15 release. Whether as a side-effect or a deliberate move to simplify the interface, clicking the flow definition of a process in the change set now redirects you to the regular Process Builder UI. Thanks to Melanie Matney for the tip-off. Despite this, we still hope and believe that getting to know how processes work and what they can and can’t do will function as a good stepping stone towards learning Visual Workflow. It was fun while it lasted!