My Nonprofit Uses Leads – & So Should Yours!

How do I love leads, let me count the ways.crm-funny1

Before starting at Year Up, I did not understand the depth of what I would learn jumping into a Salesforce org with so very much DATA as this one. Year Up is a successful (and growing) nonprofit organization with 15 sites across the country, attracting the attention of prospective students and prospective employers our interns and graduates. And up until recently, our usage of the Leads object had been minimal.

Why am I highlighting this? Because the places where we have implemented Leads our process has improved and our data has been cleaner. And the places we haven’t? Well, I’ll get to that!

Leads should be the destination for all of the unqualified data about new or prospective constituents (both from users and from your webforms). And you don’t need to be a money-making corporation or a large organization to find Leads useful. I want to talk about two main reasons for this:

  1. Putting a system in place for managing your pipeline of NEW people ensures proper follow through and follow up: Think about it, getting people in the door of your organization is the result of your organization’s success and the hard work of your marketing or communications person or team. Someone believes in your mission and wants to be a part of it! A lot went into someone finding that form and filling it out. The last thing you want is for that person to fill out the form and then get lost in the shuffle of your Contacts, or get a follow up a week or a month after they’ve filled out the form. Leads has some great built-in functionality for managing these records. Set a default owner, set a notification to that person when the lead arrives and then a reminder to follow up. Set up a queue so that if the default owner is on vacation, someone else will be there to catch those new leads.
  2. Avoiding clutter and confusion in your Contacts or other objects keeps your qualified and unqualified data clean, manageable, and separate from one another: Your prospects should be handled differently than people already in your system, right? You don’t want them receiving your organization’s mass emails, you don’t want them confused with an existing donor, and you don’t want your staff running a Contacts report full of people whose sole reason for being there is that they filled out a webform (but have yet to have a real interaction with someone on staff).

Currently, one of the ways we are using Leads is for our prospective employers of our interns and our graduates. The lead form asks for minimal information – all we want is the type of interest, and their contact information. We’ll fill in the details when we do our follow up and have a conversation over the phone.

partner leads

On our roadmap is Leads for our prospective students. Currently, all prospective students automatically become Contacts when they fill out an interest form. That means – you guessed it – that we have a whole lot of prospective student data cluttering global search results, reports, and dashboards. Prospective students all remain in the system for all time. And like other competitive youth programs and educational institutions, many prospects do not move forward in the application process or are not accepted. Going forward, we’ll have prospective students created as Leads instead, putting them into a queue to be responded to by a queue member from Admissions who connects with them by phone and makes sure they follow our standard application process. Once they are enrolled in the program, they will be converted to a Contact.

Keep in mind:

  • Standard lead conversion creates both a new Account and a new Opportunity, which is not always useful for nonprofits. If you are using the Nonprofit Starter Pack, read up on the NPSP’s Lead Conversion Utility.
  • Are you using Salesforce’s new-ish Duplicate Prevention Tool? (If not, you should be!). You can avoid creating duplicate Contacts from lead conversion if you include cross-object matching in duplicate rules.
  • Web-to-lead forms are your friend. They can be embedded right on your website, and you don’t have to do any custom field mapping, so they are great for a super basic form. You can also use FormAssembly for your more complex forms, which handles duplicates and multiple object touches a bit better.

So what are you waiting for? Check out the Trailhead modules on Leads (here and here), do a little Sandbox testing, and get to it!

Advertisements

Apsona: a Salesforce Admin’s BFF

I hajerrymaguired the honor of presenting at the Bay Area Salesforce Nonprofit User Group this week on Apsona, one of my absolute favorite Salesforce productivity apps. For the uninitiated, Apsona is a browser-based data uploader tool for Salesforce, but really it’s so much more than that. Others have written many a love poem to Apsona (here, here, and here for just a small sampling!) so I won’t do a big overview. Those of you who already use Apsona know that it can do some amazing stuff.

Did you know that you can access a lot of obscure Salesforce objects through Apsona, like Chatter Group memberships, Public Group memberships, and Permission Set assignments? Let’s talk about Chatter first.

Bulk Adding Chatter Group Members

In order to users to Chatter groups, you navigate to your group, click Add/Remove members, find the user, click Add. Easy enough. Unless you’re adding more than, say, 10 users, and then it gets pretty annoying. To add users through Apsona:

You’ll need two excel columns: one for your user ID (or user’s full name, assuming it’s unique), and one for your group ID (or your group name, assuming it’s unique). You can find your group ID by going to your group and copying the 15 digit ID right at the end of the url.

bulk add chatter group membersNext, you’ll need to add the Group Member object in Apsona. In Apsona, navigate to Settings >> Configurations, and open up the System Administrator settings to edit. Note: there are currently two objects called Group Member. One is for Chatter group members and the other is for Public group members. Add them both because it’s impossible to differentiate between them from here! Add them to your visible objects, and then to your menu bar. Click Save, and then Settings >> Clear cache so you can actually see the objects.

Click on the first ‘Group Member’ tab – if you see Collaboration: [name of Chatter group], you’re in right object! Proceed with your import and upload. Your upload is actually creating new records, so tell the system to reject duplicates. Select ‘Create new’ for match fields, and select Collaboration Group and Member. Essentially, you are telling the system not to add the user to the group if that user is already IN the group.

match fields

Click next, and complete your upload. That’s it!

Bulk Adding and Reporting on Public Group Membership

The process for adding users to public groups is essentially the same as Chatter groups, except you are looking for the other ‘Group Member’ object. You need two columns like above, one for the user and one for the group. Proceed as above.

One other nice Apsona feature with Public Groups is that it is currently not possible to report on Public Group membership in a Salesforce report. But you can do so in Apsona, using filters and the export function within your object tab. From here, you can get a basic report of your public group memberships.

Bulk Assigning and Reporting on Permission Set Assignments

permission set assignmentsSure, you could download a special app to help you deal with your permission sets, but why not use an existing tool for this? Add the Permission Set Assignment object to your menu following the same steps as above – Permission Set Assignment is the object connecting Users to Permission Sets. Again, two columns, one for your user and one for your permission set. And similar to Public Groups, you can also use Apsona to filter on and export out your permission set assignments!

Got any other cool stuff you’re doing with Apsona? Please share in the comments!

Now we’re…

managing data like a boss

Salesforce Admin Hack: Temp Fields

I ❤ temp fields! Temp fields are simple text fields, used mainly by administrators (though I have given access to superusers on a few occasions), to quickly and temporarily tag records with dummy text so you can easily locate those records later in a Salesforce report, an Apsona filter, in Demand Tools‘ Single Table Dedupe, the Apex Data Loader, or anywhere else where you can filter a Salesforce field. Here are a few ways temp fields can be useful and make you an even more #AwesomeAdmin.

To test out the examples below, start by creating your temp field. The examples below are on the Contact object but you can create a temp field in any object where it might be useful. Call it whatever you like as long as you know where to find it (“Temp Field,” “Temp Field 1” if you have more than one, etc.). Make it a simple text field, 50ish character count. Make sure that you make the field read-only for all users aside from those who should be updating these fields.

Tag a Group of Records for Easier Reporting

Let’s say a user has given you an Excel spreadsheet with a list of Salesforce IDs, or email addresses, or phone numbers, or names. Maybe the spreadsheet has IDs, maybe it doesn’t. The user wants to be able to run a Salesforce report on these people: their donation history, campaigns they are a part of, etc. The problem is, no Salesforce report filters will be able to match this list exactly because it was generated by the user, or because they took an old Salesforce report and deleted some contacts and added some new ones.

If you have the IDs: make sure the temp field you created is available in Apsona by clearing your cache after adding the field. Next, add a new column to your spreadsheet with the name of your temp field as the header. Choose any value for the field as long as it’s the same for every record. My personal best practice is to insert the date into the end of the field value so if I stumble on it later, I can remember when I used it, which will (hopefully) remind me why I used it and whether it can be cleared or overwritten. Your spreadsheet will look something this this:

TempTest0719

Copy and paste into Apsona like you are doing a record update – all you are doing is updating this one field. Afterwards, add Temp Field = TempTest0719 (or whatever your value is) as a filter in any Contacts report, and send to your user. Once you are done, clear the temp field or just leave it alone until you need to make your next update – with your next update, you’ll simply overwrite what’s already there. (that’s when having a date in the value comes in handy). See below regarding clearing the field.

If you don’t have the IDs: don’t forget that in Apsona, you can map on more than just Record ID: you can also use email, name, name in combination with address, and more. You can follow the same process as above with what you have, or if you have a mix of those different things, run each one through Apsona separately and use the backup file, which contains IDs, to do your final upload.

Merge records with Demand Tools

If you have used Demand Tools’ Single Table Dedupe function, you know it can be confusing and slightly terrifying (am I sure I want to merge all of these records with no backup??? No, not when you say it so ominously!). The UI is not the best; if you’ve pulled in the wrong fields to review, you have to keep adding them afterwards; it’s difficult to look at all the data you need to look at at once to make an informed decision about whether you are merging the right records or not; you can’t find the scenario you were working on last week, etc. Or maybe you already have created a complex Salesforce report, exported it to Excel, and don’t feel like going through the steps of carefully re-creating all of the conditions in Single Table Dedupe’s UI. For whatever the reason, I have often found it easier to review this data in a Salesforce report, either within the Salesforce UI or exported to Excel, where you can sort and filter. My favorite way to safely merge records using Single Table Dedupe is with a temp field. Once I have finalized my list of records that I want to merge, I’ll do similar to what you see in the example above, but I don’t put the exact same value in the temp field. Let’s say I’m merging contacts: my temp field upload might look something like this:

TempTestMergeRecords0719

My temp field value starts with Merge0719 but has the last name of the contact appended. Once I am in Single Table Dedupe, I can simple add a condition in step 1: Temp Field starts with Merge0719:

SingleTableDedupeFilter

Since you have already done your work in Salesforce or Excel to determine which records you want to merge, your only mapping condition in Step 2 (selecting fields to match) will be your temp field:

SingleTableDedupeMap

On the next screen, your records will display grouped accordingly. From here, determine your master rule to tell the system how to decide which record should be the master, test one to start and verify that the merge went as expected, and then do the rest. Clear your temp field from the master record after you’re finished.

Clearing a Temp Field

My best practice is to clear a temp field after I’ve finished using it to avoid future confusion. Create an Apsona filter Temp Field = your value, and update all records in the filter to Temp Field = blank. You’re finished!

There are countless use cases for temp fields, especially with Apsona and Demand Tools at your fingertips. Apsona, in particular, makes updating records such a breeze that I use temp fields multiple times a week. Do you use them? If so, please share your use cases!