Cloud for Good
Close this search box.

Process Builder and Cloud for Good Donation Split: A Case Study in Awesomeness

We’re big fans of Salesforce’s new Process Builder here at Cloud for Good. Full disclosure: Process Builder is currently in beta. Its features, user interface, and any other thing about it could change significantly before it is made generally available. As beta products often are, it’s a little rough around the edges, but you can can still do a lot of great things with it–things you might not have been able to do previously without code.

Like a lot of people who cut their teeth as nonprofit Salesforce administrators, I’m an efficiency nut. I can’t help but intervene if I see my clients doing mindless, rote work that can be easily automated. Nonprofits fight enormous problems, and solving those problems requires your brain, not your fingers clicking buttons pointlessly. It drives me crazy!

Before Process Builder, you had a lot of options for automating rote processes, but solutions for complex problems often required code. Process Builder is a great way around needing to know how to code. It lets you design complex logical rules to automate your business processes with a simple visual interface and point-and-click efficiency. It’s a thing of beauty.

With a little raving out of the way, I want to get into the details. Here’s a step-by-step walkthrough of some recent work I did for a client to automate a rote process that was taking up a considerable amount of their time. You can use this as an example and adapt it to your own needs.

The client I was working with uses Cloud for Good’s free Donation Split AppExchange app to help manage their accounting data. An event management system was creating new Opportunities in their Salesforce instance automatically when new event tickets were purchased, but they had to manually associate these new Opportunities with Designations in Donation Split. It was a big pain for a busy organization, and they needed a better solution that helped save time. Process Builder was the way to go!

First, like most organizations, this client didn’t have Process Builder enabled for their Salesforce instance. As a beta product, it isn’t available to everyone yet, but getting it is easy. Just submit a case to Salesforce support by clicking the “Help and Training” link at the top of your Salesforce instance, then click “Contact Support”. Ask the nice folks in Salesforce Support to turn on Process Builder for you, and they’ll be glad to help you out. They’re generally able to respond less than a full business day, but your mileage may vary.

Once Process Builder was enabled, it was important to figure out what kind of logic we could use to automate the process. I love computers, but it’s important to remember one crucial fact when designing solutions like this: computers are kind of dumb. They only do what you tell them to do in the most literal way possible. That’s why it’s important to stick to think in pure logic when designing solutions like this. Computers can’t figure out exceptions to rules or make interpretations the way people can.

We needed some kind of logical condition that, when always true, would let Salesforce know to fire the process. Thankfully, business needs of the organization made this very straightforward. In all cases where the new Opportunity had a certain value in its Primary Campaign Source field, we wanted the process to fire.

You would think that simply specifying the value that went in the Primary Campaign Source field would be enough, but you’d be wrong. Remember, computers are kind of dumb! While the process we were building would be able to figure out if the Primary Campaign Source had a certain value if that field had something in it, it would get very confused if the Primary Campaign Source field was completely blank, as there was nothing for it to evaluate. To that end, we needed to tell the process to only look at Opportunities that had something in the Primary Source Campaign field. I used a formula to do that, and to save you the trouble of figuring it out yourself, here it is!




ISBLANK( [Opportunity].CampaignId )) ,

[Opportunity].Campaign.Name = “Campaign Name Goes Here” ), TRUE, FALSE)

You won’t have to use a formula for every condition, especially if the field you’re using in your logic is a required one, but it’s good to know that you can if you have to.

Once we had defined the conditions in which the process should fire, we had to tell it what it was actually supposed to do. With Process Builder’s straightforward point-and-click interface, it’s very easy. What the process is supposed to do is called an “Action”. Actions can fire immediately or on a schedule, and one triggering condition can fire more than one action. Actions can come in many flavors–they can create records, update related records (even beyond parent-child records!), post to Chatter, launch a trigger-ready flow, send an e-mail, or submit a record for approval. To create a new Designation, we needed to create a new record.

First, name the action. Give it a descriptive name that will have meaning if you look at it a year or two after you’ve built it. Next, select the object you’ll be working with. Cloud for Good’s Donation Split stores designation relationships in the “Designation Budget” object, so that’s what we selected as the object to work with.

Next, specify the fields to make changes to. For Cloud for Good’s Donation Split app, it’s important that the new Designation Budget records you’re creating have an amount, a budget year, a designation, and a relationship to the Opportunity you’re working with. Let’s start by specifying the amount.

In all cases, the amount is always going to be the same as the amount of the related Opportunity, so we needed to pull in that value. If you look in the screenshot below, you’ll notice that some of the fields in the “Value” column have a pencil icon while others have an icon that looks like a magnifying glass looking at a folder. If the field is marked with a pencil, that means you’re specifying the value manually. If it has the magnifying glass icon, the action will look up to a related object for the value. To that end, we clicked the pencil once, which made it from a manually edited field to a lookup field, and made it equal the amount of the related Opportunity. Easy! We did something similar with the Opportunity relationship. We made it a lookup, and told it to find the ID of the related Opportunity.

The Budget Year and Designation were a little trickier, but still pretty easy. Each Budget Year and Designation is a unique record, and you’ll need to add the ID for that record to each of these fields. Getting the ID is fairly straightforward. Just navigate to the related Designation or Budget Year record and look at the URL bar. At the end of what’s in the URL bar, you’ll see a string of 15 nonsensical characters. That’s your unique ID!

When you’re done, activate the process with the “Activate” button at the top and you’re just about done! The last and most important step of all is to test, test, and test your process again. If everything works as intended, congratulations! You’ve automated a business process and saved yourself or your colleagues hours of mindless drudgery!

Like this article? You might also enjoy: