Guest Post: Flow Solves Chicken vs. Egg Problem

I am pleased to present a guest post from Michael Kolodner. Michael is a self-taught Salesforce admin, a competitive saber fencer, and the keeper of four backyard chickens  Three years ago, Michael recommended Salesforce for a CRM in a young organization, mainly because of the ten free licenses. Later, Michael consulted to a sister organization that wanted to implement their own Salesforce database, building that one from scratch on the NPSP. Michael now is the Systems Administrator for Spark, an education nonprofit with 50 users and a much larger database. He is interested in growing his skills and becoming certified soon! He’s working to pay back the great help he’s gotten on the Hub by answering others’ questions whenever he can.

Michael shared his quest on the Power of Us Hub, and like any proud and wise hubber, agreed that these trial-and-error processes that end in successful automation ought to be shared. Take it away, Michael!

The other day I started in on what looked like a simple task: Build a Process that will create two records (Student Nomination and Report Card) when a student (Contact) is enrolled into a program and has evaluation consent. Even allowing for the fact that I just listed three custom objects and a custom field on Contact, I bet you understood the gist of that request. And it sounds simple, right?

Just you wait. It’s still going to sound simple for a sec while I let you know about my organization and my Salesforce instance.

Spark is a national nonprofit that re-engages underserved seventh and eighth grade students, keeping them on track and ready for success in high school and beyond through workplace-based apprenticeships that uniquely combine mentoring, project-based learning, skill building and career exploration. We use Salesforce to keep all of our program data and development data–to run the whole shebang, truly!

As it relates to this blog article, you need to know that:

  • Students are a record type of Contact. (Actually, you didn’t really need to know that. And you’d probably figured it out. OK, moving on…) The evaluation consent custom field is a checkbox indicating whether or not we have gotten consent from the student’s family to use their data (grades, etc) in our impact studies. The fact that it’s a checkbox is all that will be on the test that follows this article.
  • Enrollments is a custom object that indicates when a student is part of one of our programs at a school. The Enrollment links the Contact to the Program. Creation of an Enrollment object is the moment at which, as far as Salesforce is concerned, a student has been accepted into Spark’s program at their school. Enrollments are detail to both Contact and Program.
  • Student Nominations is a custom object that holds data about why the student was recommended for Spark (attendance info, social and emotional measures, etc). We used to get them as our first introduction to a student, but now we get a student’s paper application and then hear from their teachers about them, there is no separate nomination form. These are a detail object to Account.
  • Report Cards is a custom object designed to hold grades and data when we get it from the school district. These are a detail object to Contact.

data model

When a student is enrolled, I wanted to create empty shells of those two objects that could be filled later when we get data for students.

So… Simple, right? Just make a Process that fires upon creation of an Enrollment. The criteria will be that the related Contact has True in the evaluation consent field. Then the action will be that it creates two records: a Student Nomination and a Report Card. Getting slightly more into the weeds, we want to make sure we create those two records of the proper record types and that we fill in a couple of fields, like relating said Report Card to the right Student.

Easy peasy! I created my Process. And, sure enough, it fires just fine and creates a Nomination and a Report Card. And, having put the Student on each one, they show up in related lists on that student’s Contact record.

It’s what I realized next that sank me: There is also a lookup on the Report Card to the Student Nomination and vice-versa. It didn’t take me long to realize that filling those in was going to be a bit of a problem. My Process can’t fill them in right away because neither object exists yet for my Process to grab its record ID.

Still, I wasn’t fazed. I’ll just build two more Processes. (There’s nothing you can’t solve with more Processes, am I right?) Each would fire on creation of the record (the Report Card and the Student Nomination) and then fill in the record ID of the created record on the lookup field of the other one.

no dice.jpg
No Dice.

I immediately got an error that “The flow failed to access the value for myVariable_old.nominationform__r.Id because it hasn’t been set or assigned.” You see? The ID still hasn’t yet been assigned because even my new Processes are running before record creation has actually finished. That’s when I turned to the HUB for help. Great resource, that. Smart people, helpful, and fast. Sadly, that’s where I learned that you can’t control the order or timing of processes.

The path forward was a Flow.

But don’t worry – not nearly as complicated as this!

I’d done the Trail on process automation. (You do know about Trailhead, right? Tons of totally free interactive Salesforce training!) And I looked at the Flow designer workbook. But this was basically uncharted territory for me.

The first key to working with Flows, I quickly learned, is that you have to be organized up front. And even if you’re a declarative (or “button click”) Admin like I am, you have to at least pretend to think a little like a programmer. (Don’t worry–we’re just going to pretend!)

What I mean is that we’re going to have to define a handful of variables to use as we step through our Flow. Unlike in a Process where you can look up an object or field at the point you need it, in Flows you have to define a variable to represent that object or field and then point to that variable at the point you need it. These variables get created on the Resources tab (1) and, once defined, show up on the Explorer tab (2) of the interface.

resources tab

explorer tab

You can create those variables later in the process, but you’re a little bit in danger of losing your place as you do so. I recommend thinking through the variables you’ll need at the beginning and setting most of them up right away.

Below, you can see the variable I set up to hold the Contact ID of the student whose record I’m going to want to attach things to. In this case, my Process will actually set the value of the variable. I’ll show you that in a sec.


Here’s the variable for the Report Card object that’s going to be created in the course of the flow.

report card variable.jpg

For those of you keeping score at home, I needed a minimum of three variables that you’ve probably picked up on:

  1. The Contact ID of the student we’re talking about. (Set by a Process.)
  2. The record ID of the Nomination Tool created during this Flow.
  3. The record ID of the Report Card created during this Flow.

(If you really must know, I also used three more variables, as you may have noticed in my earlier screenshot: the student’s School Name and the name fields for the two objects being created. There’s nothing particularly interesting about those variables and I found them easier to define by putting a formula in the Process than here in the Flow.)

Now let’s take a quick peek at the Process that actually kicks this Flow off. (NOTE: You won’t be able to build the Process until your Flow is finished. But I’m showing you this here for context, not chronology.) The action runs my Flow after filling four variables for me (1-4 on the image). Those are the variables we’re talking about creating right now.


All right, back over to the Flow Designer.

Here, we come to the part of the Flow building that I would actually say is fairly intuitive. You have a canvass in the Flow Designer onto which you drop your actions and then link them with arrows.

record create report card.jpg

To get that Record Create box, I just dragged the Record Create step into the canvass. Salesforce immediately gives me the record create dialog that I have to fill. Here I’m showing it to you scrolled down so you can see that last step, with the bright red arrow. (The arrow’s not there in Salesforce. But you probably figured that out.) That’s where the creation of this record fills one of my variables with the record ID of the record that was just created. I bet you can already see how that’s going to be helpful down the line…

record create report card 2

I have created the Report Card record and now I need to create the Student Nomination Record, a second step in the Flow. Once that’s done, I will make steps three and four that auto-fill fields on the two records created in steps one and two. I’ll do that by using those handy variables I filled during the record creation steps. Nothing brilliant to see, but here’s one of those update steps. Notice that it uses the variables we defined at the beginning, which have been filled as we went along.

record update put lookups on student record

(Give me a sec, Let me work a bit more… Workin’ on it…

There! I have 4/5 of my Flow laid out. Just now I added the step to update the record that was created at step 2.)

create pre spark report card.jpg

Once I drag down from the little diamond next to the star, I get an arrow to link it to the last step in the chain.

create pre spark report card 2.jpg

And did you notice that little green arrow in the upper right of the first box in my Flow? When you hover over a box, you get options for Edit, Delete, and to set this element as the start of the Flow. (You’ve got to have one set as the start before you save.)

set as start element

That’s really all there is to it. Save your Flow. (Then don’t forget to Activate it.)

flow versions.jpg

Now head on over and create your Process to fire the Flow.

Since you’ve done all this in a sandbox, you can test to your heart’s content. (You ARE working in a sandbox, right?) And when you’re done, upload via Change Set to Production and give yourself an ice cream cone!


Report Subscriptions = Self-Service Email Alerts

“Can I please have an email alert every time X field/record is created/modified?”

This request!!! Ah! Once users begin to fully understand the wonders of workflow rules and email alerts (which is awesome), they may start to make some superspecialsnowflake individualized requests for email alerts (rut roh). Alerts for everyone! On everything!


Wait, no. That’s actually a terrible idea. If you start flooding your system with special workflow rules requested for each individual user, you’ll choke up your system in no time. And you’ll have to devote time to testing and tweaking those workflows. If you’re a larger org, it’s probably already general policy that your support team simply turns down these types of requests.

Report Subscriptions came out in Spring ’15, and I spoke at Dreamforce about administrators using them to monitor data quality. Since then, I’ve also begun directing our non-admin users to this handy new feature in place of workflow email alerts, and it’s been a big hit. Why do I love this feature?

Report Subscription Button

Scooby loves self-service!

Self-service: Users can set subscriptions up on their own, which means they can edit them to their heart’s delight, set up new ones when they feel like it, and unsubscribe when they’re done. Without ever involving an administrator! High five, fellow admins! It also means that when they leave the organization and their user account is deactivated, those alerts simply go away instead of needing to be manually changed to another user (as is the case with workflows).

Self-service also = administrator time saved: Time saved for me and my co-admins that we’d otherwise need to dedicate to setting up and testing the alert, and then time later on for modifying it, and then even more time when that user leaves the organization and needs to be deactivated, but first they need to be removed from the alert and then we need to find out from their manager if someone should replace them as the recipient. Etc. You’ve been there. Maintaining workflow rules is not simple, and maintaining personalized email alerts for every user is just not a sustainable business practice.

The key to using Report Subscriptions for these types of daily or weekly alerts is to use Dynamic Date Criteria in your filters. Say a user wants to know every time an Opportunity associated to a specific Contact or Account closes. You’ll want to set your Close Date filter to the dynamic ‘Yesterday’ and your alert schedule to ‘Daily.’ That way, on January 29th, they will receive an alert of donations that met their criteria on January 28th, and so on. If donations come in over the weekend, they may need to modify the criteria slightly when they re-run the report on Monday morning. But otherwise, this comes pretty close to perfect! You can similarly use ‘Last Week’ and set your schedule to run weekly.

Report Filter Criteria

Report Subscription Edit

Of course, the criteria in a report won’t necessarily be as granular or detailed as workflow criteria, and you can’t set Report Subscriptions to notify you immediately, the most often you can have it notify you is 1x a day. They cannot replace workflow email alerts for everything, obviously. But they can certainly meet a lot of notification needs for individual users.