Using Leads in Program Management

The Salesforce platform is built to be flexible, and making creative use of standard objects can support a wide range of functionality. Increasingly nonprofit organizations are looking to manage multi-step support cases -- instances in which an individual must be deemed eligible for services before a case is created, or perhaps there is an intake process before the type of support is identified.

The most common solution for program management is to identify a process within the confines of a Case - statuses to mark the Case as not-yet-approved or going through intake. This solution works; there’s nothing wrong with it.

But what if there’s a chance that the person requesting support isn’t eligible for that support at all or perhaps ultimately not interested? What happens with the handful of Contacts, and their associated Accounts or Households, that are created at the outset but never go anywhere?

There should be a way to identify an incoming request that still needs an initial review. Are they eligible for services? Have they marked off the boxes needed before they can receive services? Are they even interested in the available services? And is there a way to easily distinguish between eligible and ineligible applicants?

Leads can serve as this early stage of pre-eligibility review, and Process Builder makes it possible to auto-create a Case upon conversion, signalling the initial approval of an incoming request.

Why Leads

 At its core, the Lead object is just a holding area for those ill-defined, not-quite-a-Contact-but-not-nothing types of records. They are individuals that we have some knowledge about but may require a go/no-go decision before moving forward. Ephemeral, elusive, and extraordinarily helpful.

They are easy to get into the system, either through an import or even Salesforce’s built-in Web-to-Lead form. Forms can have minimal information to make a client feel at ease, and follow up or more in-depth review and questions can come later.

From a strict database perspective, Leads take up less memory than a Contact and associated Account, being only one record with data pertaining to both. They are easy to auto-assign, transfer, and even delete, if necessary, and they can also still be assigned to Campaigns for nurturing and tracking. They also serve as a clear indication to all users that this is a person or request that has not yet been picked up and reviewed.

The conversion process is already tracked and catalogued by Salesforce, so it can be a trigger or switch that indicates to the system, as well as users, that this individual is ready to receive services.

Prepare for Case Creation

Creating a case on conversion, like creating anything else from Lead conversion, requires some planning. Some key questions to ask are:

1. What information do we require to confirm initial eligibility or interest?

2. What information needs to be copied to a Case?

3. What information needs to stay with the Contact record but be included with the Case?

4. Are there different types of Cases, and if so, does the type need to be identified even at the early Lead stage?

 For each of these questions, prepare the database to work within those requirements. Create any custom fields on the Lead, so they can then pass onto the Case, and make sure to create custom fields on the Case to accept that data, if necessary.

Here is an example of one way to manage thinking through and creating these types of custom fields. 

What about that pesky Company field?

Depending on your overall database, you may want to change the label of this field to something like “Family Name.” If you need to keep it as-is for a multi-use database, train users to include something along the lines of “Requester.” Third party form builders will also allow you to set this value automatically.

If you’re using NPSP, the Household Account will be renamed on conversion. If you’re not using NPSP or are not using the auto-name feature, teach your users to use a specific naming convention.

Build the Automation

The goal is to create a Case when the Lead is converted. Process Builder can handle this all on its own. For this demo, only one type of support is provided, but this same concept can be expanded and made as complex as needed. 

1. Name and describe your new Process Builder flow - good documentation is best practice. If possible, make note of any exceptions, as well.

2. Select Lead as your Object and “when a record is created or edited”

3. Identify the first criteria. It’s important to at least include that the IsConverted system field is changed and is now true. Other criteria can be included. Here are my conditions.

4. As an immediate action, select “Create a Record” and choose Case as the object

5. Use Lead fields to populate fields on the new Case with the Field Reference option

6. For Contact and Account ID, use the Field References “Converted Contact ID” and “Converted Account ID” respectively

7. Save and test

 Leads are an option for managing a multi-step program management process, and with Salesforce’s growing solutions for automation via clicks-not-code, it’s easier than ever to utilize this native solution and still make it easy for users.

Have you used leads in a similar way? Do you have a similar use case that you solved in a different way? We’d love to hear about it. Share your stories with us on the Salesforce Community or chat with me @thesafinhold .