I love the new Salesforce Visual Workflow.

I can’t code a line of Apex but with Flows, I can automate processes in ways that just warm the heart of my inner wannabe geek. As hard as Salesforce is trying to make Flows approachable, it still comes across as scary to many admins, especially those working at small nonprofits. I’m not finding many Flow use cases for nonprofits built out in enough detail that folks can follow/adapt for themselves. So I thought it might be fun if I documented a Flow I recently built.

I serve as Financial Secretary for my tiny all-volunteer synagogue. Of course, I set them up on Salesforce. The instance is running the latest version of the Nonprofit Starter Pack packages, most of which I’ve heavily customized for the synagogue’s unique processes. As it’s a synagogue, I’ve also built out additional functionality around Yahrtzeits (memorials), High Holiday pledges, High Holiday ticketing, Membership and Hebrew School enrollment.

I’m in it constantly to record gifts, run reports, analyze giving history, etc. Everyone else primarily uses Salesforce as a member/connection database which is just fine. We have no paid staff working out of a central office (besides our Rabbi and Janitor). All volunteers have day jobs that have nothing whatsoever to do with technology.

I taught those that needed to how to edit records when needed. How to run reports. That’s easy. The challenge was when they needed to enter a new prospective member/family. I created a ScreenSteps document to show them step-by-step how to enter a new contact/household and distributed the PDF via email. It’s 14 pages long. I’ve sat next to folks and coached them through. Still, they weren’t happy, and with good reason. The process is a pain and I know it. Could be easier with triggers, sure. But I can’t write a trigger and this organization has $0 to spend on letting me hire someone to do the work.

To add a new prospective member they need to:

1. Search to see if contact already exists.
2. If the contact doesn’t already exist, create the contact for the primary member.
3. Fill in their name, email address and mobile phone (household address and phone are on the household record).
4. Save the record, the Household is automatically created.
5. Edit the Household record to insert the mailing address.
6. Set the contact just created as the Head of Household on the Household (this is Common Ground functionality I “borrowed” for this org and allows for cross-object formulas and workflows via clicks that wouldn’t be possible if the contacts were only related to the Household via child records – but since I can’t code this can’t be linked automatically the way it is in Common Ground).
7. Set the correct Household type (typically “Prospective Member”) and save the record.
8. Add the spouse’s contact record, if known, to the Household.
9. Edit the Household again to set this new contact as the Secondary Contact. Saving the Household record will automatically update the Household name.

Gee, I can’t imagine why these non-technical folks thought this was difficult?!?

Enter Salesforce Visual Workflow. I reduced the above 9-step, 14-page process for my volunteers down to just this single screen they need to fill out from a URL I had them bookmark.

One screen. They enter as much as they know, click “Next” and everything happens for them in the background, including checking to see if either the primary contact or secondary contact already exist, and if so, the flow ends with a link to the existing record which they can easily edit or leave as-is.

Flows are so much easier than they look.

Here’s the final Flow (image edited with the red numbers):

Here’s the step-by-step logic going on here:

1. A screen to collect all the data. In my first version of this flow I had broken it up into multiple screens depending on whether or not a secondary contact needed to be created. In the end, I decided it’s about my users’ convenience, not mine, and I thought it better to collect everything in one screen. In a Flow, what you collect automatically becomes variables you can use later. Doesn’t matter in what order you collect it.
2. Do a record lookup to see if the required primary contact exists. I can only match against first & last name because that’s all that’s required. I’d love to see some conditional logic in a later version of Visual Workflow so I can script something like “If email address is entered, match that otherwise match first/last name.” For now, this will do. At worst it will create a dupe that will have to be cleaned up later but it should catch basic duplications.
3. Also see if the secondary contact already exists. In both cases, if the record already exists, create a variable for the Contact ID since we’ll be linking there in the final screen.
4. Decide what to do if either contact already exists. Here you can use an OR statement, so I did.
   
5. If either contact already exists, the flow is over. In future versions of this flow I might add a screen for adding another contact to the existing household, but for now they get a link to the contact that already exists and they’re done.
6. If neither contact exists, the flow moves on. First, the new Household record needs to be created. I found in my testing that the automatic Household creation didn’t fire on a flow-created contact, so I need the step that does it. It will, however, properly create the one-to-one account so that won’t have to be done manually. This process creates a new Household record, filling in the address from the entry screen and making up a default dummy name since the correct name will be automatically changed when saved according to household naming rules. The newly created Household ID is saved as a variable since it will be needed later.
   
7. Now it needs to create that primary contact. It’s just a matter of plopping in the fields that the user already entered, plus the Household ID just referenced. That new contact’s record is also saved as a variable for later use.
8. Next, the Flow needs to decide if a secondary contact record also needs to be created in the Household. This is based on whether there’s any data in the entry field for the Secondary Contact’s first name. If no, jump ahead to step 13.
9. If yes, a second decision has to be evaluated: Does the secondary contact have the same last name as the primary contact? I wanted to make it as easy as possible for my volunteers. They can just enter a first name for the secondary contact and the Flow will assume the secondary contact has the same last name. Otherwise, they can enter a last name for the secondary contact. They don’t have to.
10. If the secondary contact has the same last name as the primary contact, then the secondary contact record is created using the Last Name input field of the primary contact and is linked to the Household previously created. Otherwise,
11. the secondary contact is created using the last name that was entered for the secondary contact. In both cases, the new contact ID is saved as a variable.
12. Once the secondary contact is created, the household record needs to be updated to indicate the secondary contact reference link.
13. Regardless of whether or not there’s a secondary contact, the Household record is updated with a reference link to the primary contact.
14. End the flow with an easy link to the new Household record the volunteer can follow and see what they’ve done.

Seems like a lot is going on here, but after the volunteer enters data and clicks “Next” it all happens in a few seconds.

From this:

To this in a single click:

I’d love to hear of other use cases for nonprofits. Let me know how you’re using it in the comments.

You can also check out Salesforce Foundation developer Nick Bailey’s excellent Dreamforce session on Visual Workflow for nonprofits: