For a button-click administrator like me, the introduction of Lightning Process Builder was life-changing. I’ve been creating records, updating multiple fields, and kicking off multiple email alerts like a boss! At Dreamforce, I presented on “Tips and Tricks for Nonprofit Administrators,” which included a lesson on using Process Builder to automatically add users to Chatter groups based on data from the User record. Huzzah!
OK, so when I discovered the above was possible a few months ago, I went nutty with the Chatter group adds, and then I thought, why can’t we do this with Public Groups? YES WE CAN. Add a new Process? Don’t mind if I do! Then, a third one for permission sets. I rule all!
Wait, no. Somewhere in there the errors started, and all three of these processes stopped working, and I was sad and really busy so I deactivated and ignored for a few weeks.
At Dreamforce, I attended a session presented by Ashima Saigal and Margaret Fako about Process Builder and Flow (p.s. you can now see the video from their session!). I got a lot out of learning about their trial-and-error process in reaching their solution, and about how much more granular and fine-tuned you can be using a flow (rather than a process) for all the details of your automation. Feeling inspired, I got to work on putting all three of those pieces of automation – auto-assigning Chatter Group membership, Public Group membership, and Permission Sets upon creation of a user – into a single flow, kicked off by a process.
I’ll start with some quick flow newbie tips to save y’all some time in the future!
- Use a clean sandbox. I was originally using my organization’s only full sandbox to test, which hadn’t been refreshed in a couple months. Flows can have errors coming out of every unpredictable crevice of your org, and the cleaner the environment, the easier and quicker time you’ll have troubleshooting. I refreshed a new sandbox and started from scratch, which eliminated one of the errors I was seeing the first time around.
- The magic happens in the record lookup. OK, I know this is a gross overgeneralization because there are a million things you can do with flow, and clearly a lot of stuff happens elsewhere, but the crucial piece that I didn’t get when I started is that you need your Record Lookup component to pull every field you need to reference later on in the flow as a variable. Now I say DUH – and you might say duh – but this is a key point I feel like I need to make for my fellow novices. If your variables are pulling the right data, you are halfway there!
- Add flow components one at a time, and test in between each one. Might seem time consuming but makes it a lot simpler to locate errors along the way and fix them as you go.
- Use your resources, like the amazing, stupendous, Power of Us Hub! How much do I love all of the amazing people who gave me great tips and helped me not only do what I needed to do, but helped me understand how flow works and why the errors I was getting might have been happening! If you have a hub login, check out the thread. When you start asking your own questions on the Hub or the Success Community, screenshot the crap out of your post. No one can help you unless they see what you’re doing under the hood. Another great resource is the Visual Workflow workbook, which has some great overview info and provides examples for flows and flow components.
Let’s get to it! Here’s the beautiful flow, which I pushed to my production environment yesterday. I’m tempted to make this my Facebook cover photo.
Record Lookup. We’re looking up the User object, and we’re pulling all the fields we need or might need as new variables (which we are creating as we go).
Decision. The first action we’re going to take here is based on the Profile of the User. In my testing, I found that for some reason, flow was having a hard time with the Profile ID field, so I created a custom formula text field to just pull the name of the profile. Easy enough.
Record Create. We’re looking at three different profiles, two of which will indicate that the user needs to be added to a Public Group, and one of which needs to be assigned a permission set. Afterwards, the users with the former two profiles need a different permission set. All three of my actions need the Record Create element. The record you are creating for Public Groups is GroupMember; for Permission Set Assignments it’s PermissionSetAssignment; and for Chatter Group Membership it’s CollaborationGroupMember. The Record Create elements for all three are quite simple: you need the ID of the user (in this case, it’s my variable) and the ID of the group or permission set.
Next, permission sets. You might be wondering why we don’t just add the permissions directly to the profile if we are assigning permission sets based on profile. You would be right to wonder. The reasoning is too long and complicated to get into here. But here’s what the Record Create looks like for it.
So now, the Wait Element. This was the trickiest part for me. Chatter Group membership and User together are one of the pesky object combinations that cause DML errors. I’m not a developer but you can read all about these fun things here! Essentially, we need to have the flow wait a moment to ensure that the User has been created before proceeding with the Chatter membership add, or else we’ll get a mixed-DML error message, which reads something like, we can’t add this user to this group because the user doesn’t exist yet. A wait element will cure all your DML ails! This Wait element waits 1 hour following the Current Date/time that the flow ran before adding the Chatter members. I figured this piece out with the Visual Workflow workbook, by the way.
Now that our flow knows to wait, we can proceed with our Chatter adds. Our Chatter adds are based on a custom field on our User object called Site. We do have sites that don’t have their own Chatter groups – those users are simply getting added to the All Staff Chatter groups, of which there are two down at the end of the flow. Everyone else gets added to those groups as well, after they’ve been added to their respective site’s group.
Finally, tying everything together is the Process that actually kicks off the flow. Two crucial points here: 1) This process uses a wait element of 0 hours after creation for the action. Ask a developer why because I have no idea. Probably a mixed DML issue. I just know it works, and kicking off the action as immediate doesn’t! 2) It references the User variable from my flow – this is so that your process knows on which user to perform the action.
My biggest takeaway here: Process Builder is a wonderful tool that I will continue to use when the actions are relatively straightforward. However, when you have multiple actions taking place with different IF/THEN statements, or if you need your process to wait in the middle without having another blue diamond, or you need granularity or more control of each action, flows are your new best friend! Get cracking!