Lessons from the Trailhead – Workflow Rules and Visual Workflow

At events like Dreamforce I never feel more keenly that it would so super awesome to have a clone or two that I could attend all the sessions my little Salesforce junkie heart desires. I spend waaaay too much time before DF shopping for the optimal collection of sessions. At least I do that beforehand…during DF I tend to wing things and change sessions up on instinct.

I’m generally not disappointed, but this year I really wanted to make it to some of the sessions on the different options for workflow-related functions in Salesforce — Workflow Rules, Visual Workflow and Apex. I wanted to get a solid handle on when each tool is appropriate under what circumstance. I have a pretty broad understanding of Workflows, and have used them pretty extensively within my org, but outside of a HOT, I’ve not touched Visual Workflow and as we know, I’m still working on keeping my Apex hammer from jumping out of my tool-belt and getting under the floorboards never to be seen again.

So I was really happy to see that the first module in the Intro to Visual App Development trail on Trailhead relates to Workflow Automation, e.g., Workflow Rules and Visual Workflow. This post is to talk through when you would use one versus the other.

Workflow Rules Basics

Workflows are actually very powerful. I do most of my work in automating Salesforce (so far) with Workflow rules. It’s also how I trigger a sync from Salesforce to my backend ERP (think accounting and fulfillment software). Workflows are triggered by rules. These rules can be very restrictive or pretty broad…it’s all up to your needs. The detailed workflow setup tasks are outlined many places, but I want to cover the overview, with some highlights that helped me get my head around when to use them.

Imagine this scenario…

You want to enforce ownership of new and existing Accounts who’s mailing State/Province codes fall under certain states. For simplicity, let’s just say that any time an Account is entered with the Billing State/Province of “CA,” then you want that Account to automatically be assigned to your best salesperson, Jane Smith.

How would you do that with Workflows?

Workflows are located in your setup under Create > Workflows & Approvals > Workflow Rules. To create a new Workflow click “New Rule.” Below are things to think about when creating Workflow Rules:

Choose which object will trigger the workflow — e.g., fill in the blank, “When I create/edit a/an ______<choose object> record I want something to happen.” So, if you want to trigger something every time you create a new Account, then the workflow would be attached to the Account object.

Choose the criteria for triggering the rule — These are really split into two categories, Evaluation Criteria and Rule Criteria. I’m actually going to handle them in reverse, because the latter is easier to comprehend than the former.

Rule Criteria — e.g., this is where you set up the “Rules” what value need to be present (or not) on the record in order for the Workflow to trigger. So in that case, you’d setup that it would trigger when:a) the account owner wasn’t Jane and b) that the Billing State/Province was “CA.”

Rule Criteria Setup

Evaluation Criteria — This is where you would say if the workflow should trigger just on new records (i.e., on record “creation”) or on new and edited records. If you choose the latter, then there is one additional option, that took me forever to understand.

Evaluation Criteria

So what’s the difference between the two following options?

created, and every time it’s edited — every time a new record is created and any time a record is edited, then the workflow rules will be looked reviewed to see if the workflow should trigger.

create, and any time it’s edited to subsequently meet criteria (say what!?) — That one took me foreverto understand, and bears some more explanation. In our example scenario, we could set the workflow to run every time the record is edited, but then we’d be triggering it even when the record was perfectly set up (e.g., California account and ownership already assigned to Jane). That seems like a lot of unnecessary work for Salesforce to do (and we like to be good neighbors and not use more resources than necessary). So we would set it to the last option, and the workflow would trigger only if the Account isn’t assigned to Jane, but should be.

Set up one or more workflow actions — these currently come in four flavors: New Task, Email Alert, Field Update and Outbound Message (the last is what I use to trigger an update to our external ERP). In our example scenario, we want to set a new Field Update to assign the Ownership of the record to Jane Smith.

Activate the workflow — very important! If you don’t activate the workflow, it will just sit there, sad and alone, waiting to be asked to dance.

So that’s workflows, but what is this “flow” all about?

A River Flows Through It

So we know now that Workflows are:

Tied to a specific object

Based on rules

Can be set to run when the record is created and/or when it’s edited

Can have one or more actions that can take place on the object in question

But how does this differ from how you use Visual Workflow?

To quote Trailhead, “Visual Workflow enables you to create flows, which are applications that are user-triggered instead of event-trigger.” I find this a tad confusing, because “user-triggered” almost inevitably creates some kind of event (e.g., button pushed or link clicked), but in this case Salesforce means that you use Flows to collect information from the user, which then can be send to a variety of objects and trigger different branches of a flow, depending of what the user inputs/selects.

So Visual Workflow:

Can update record fields

Creates flows (which are applications)

Is user triggered

Interacts with screens to help display and collect information from users

Can act upon multiple objects

Can be incorporated into Visual Force and Apex to further customize the user experience

Where do you create Visual Workflows?

Visual Workflows are created using the Cloud Flow Designer, which is a pretty cool no-code-needed, point-and-click tool. Again, this Trailhead module has a good general orientation to this tool and how to use it. I suggest working through the exercise before attempting the challenge, and really think about how various objects referred to in the challenge relate to each other.

This is a pretty deep topic, which this post only scratches at, but if this sounds like something you could use, I highly recommend you checking out this the Trailhead Workflow Automation module. After completing it I can see all sorts of reasons I’d want to use Visual Workflow, especially if I wanted to create a “quick and dirty” (or is that “cheap and cheerful”) data entry screen that then triggers updates on multiple options. Hmmm… that’s got me thinking… which for me is the point of doing all these exercises.