Posted on

NPSP Data Import Stories

NPSP Data Import Stories

The NPSP Data Import Tool is a relatively new thing. I believe it was provided to give assistance to organizations who were switching to NPSP from legacy systems. Creating all the records in the proper order and with the proper linkage between contacts, households, org accounts, affiliations, donations, payments and so on can be daunting. And NPSP Data Import Tool makes that easy. It’s the tool of choice or migrating data into NPSP!

However, as I tried to help others use the tool, I realized that there is more to the story than simply importing data. Let me explain.

Quick Overview of NPSP Data Import Tool

Each line in your spreadsheet will be imported into a record called a NPSP Data Import record and will then be analyzed by the NPSP Data Import Tool and mapped onto one or more related records, some new and some matched from existing records. This is a complex but powerful idea.

The NPSP Data Import record is a flat representation of a bunch of information. But once it is processed, you can follow links to individual two contacts, one household, one organization, one affiliation, one campaign, one donation, and one payment. And you can tell if the processing succeeded, created new records, matched old records, or failed. If it failed, you can edit the flat data right inside Salesforce and try again.

Stores are at the heart of

 ...  read more

Posted on

Extending NPSP Data Import Tool for Cases

The NPSP Data Import Tool is my favorite way to do things automatically. I had the need to add cases based on web signups. Here is my very simple journey to a very satisfying result.

The Need

I had the need to add cases based on web signups. Examples include requesting a speaker, filling in a service project request form, using our contact form to ask for something. These fall outside our automation and require cases. But I wanted to use cases so we know how many of these things come up and how well we do with them.

It was super simple and fully declarative to extend the NPSP Data Import Tool to do this. But first, why do it at all this way?

I want to keep duplicated to a minimum and I want to be safe from NPSP changes in the future. By using the NPSP Data Import Tool scheduled batch features, I can import data and let NPSP worry about matching existing contacts, adding households, and adding people to campaigns. And with my extension, I can easily create cases, too!

Here were my steps to a fully declarative solution

  1. Add fields to support cases on NPSP Data Import object.
    • I am using the following fields on the case: Subject, Description, Internal Comments, Type (picklist), Origin (picklist) and Reason (picklist). So I needed each to be on the NPSP Data Import object to specify how the case should be created. I made all the fields on the NPSP Data Import object text fields of sufficient length to minimize maintenance.
    • Case Subject Case Description Case Internal Comments Case Type Case Origin Case Reason
  2. Add columns in my Google Sheet Template
    • I have one Google spreadsheet where I keep all my data that I want to import. This way I just have one template. I started with the import template provided on the Power of Us Hub. But I have added several custom fields to supported objects. This was my first attempt time to be adding a new object.
  3. Add support for moving data rows, including my new columns for cases, from the sheet to a new Salesforce NPSP Data Import record using Zapier.com.
    • Zapier.com is a cloud automation tool. I use it to connect all sorts of things like Salesforce, Gmail, Google Sheets, my phone contact list, Trello, Twilio and more. Each Zap is a simple recipe stating that when something happens on one cloud tool, do something on another. Zapier provided a starter package for nonprofits free of charge. I use a higher level of services now after more than a year of Zaps and pay a reasonable and discounted monthly charge, the equivalent of about two hours of manual data entry, but Zapier takes care of several  thousand manipulations per month. For me, it’s a great bargain!
    • I created the Zap so that each time a row is added to my data import spreadsheet, All the data columns are transferred to a new NPSP Data Import record in Salesforce. That’s really all it does.
    • How does data get into the import spreadsheet? Normally it gets there by another Zap from a form submission. Each form requires filling in different columns… some a few and some many.  But this is a story for another blog.
  4. Scheduling the record to be imported nightly
    • NPSP Data Import Tool has a great batch import function. It’s covered in the Advanced Admin Guide. It requires setting the batch type on the NPSP Data Import record and creating a NPSP Data Import Batch configuration for each batch type. In the configuration, you can specify what type of matching to use for each record.
    • When the NPSP Data Import tool processes a record, it updated the record with matched or created contacts, accounts, donations and payments and marks the record as successfully processed.
    • Any record unable to be imported, will be marked as a failed import. You can view it later, edit the record data to fix the error, and it will get imported again on the next run.
  5. Creating a Process Builder to wait for NPSP Data Import records with my new case fields to be marked as successfully imported during the nightly run.
    • The NPSP Data Import Tool finished up with it’s part of the job, but there is no case record yet. So this is the job of Process Builder! The Advanced Admin Guide covers how to implement APEX classes to post process NPSP Data Import records, but I wanted a declarative method.
    • My Process Builder watches for NPSP Data Import records modified so that the status is newly changed to successful import.
    • If any such records contain case fields, my Process Builder goes to work and creates a new case record using the data on the NPSP Data Import record. It updates the NPSP Data Import record with a lookup to the newly created case.

So that’s it! In less than an hour, I had extended the NPSP Data Import Tool to support creation of new cases!

What’s

 ...  read more

Posted on

Using Salesforce to Manage a Print Newsletter

First of all, this is far from managing everything. Really all we’re doing is recording subscriptions, removing subscriptions, maintaining addresses, and generating mailing database. The content is created manually with no magic what-so-ever. But all of these things are easily done in Salesforce using NPSP.
=&0=&This is done using a multi-valued picklist on the contact. Why? Because we expose it on our website for self-service sign-up. See sign-up.StreetYouthMinistry.org.

We have a campaign called master-print newsletter which has everyone who has a subscription.

We run a report from time to time (scheduled automatically) that pulls out contacts who have this print newsletter in the picklist but who do not have a membership in our master print newsletter campaign. When this report isn’t empty, we add the contacts to the campaign with status “completed” and that’s it. Subscription done! We have considered emailing people to let them know that we’ve added them to the newsletter but we don’t currently do that. If we did, it would be an automatic email triggered by adding someone to the campaign with the status “confirmed,” and sending the email would update the status to “completed.”

=&1=&From time to time a scheduled report comes out that lists all members of the campaign grouped by status. The report is sub-grouped by the Newsletter field. So we can quickly see if there is anyone who doesn’t have the print newsletter in the picklist field but who was in the past added to the master campaign. And we can see quickly anyone who has asked to be removed but still have the value set. This audit just helps make sure our data makes sense. We could do this by process builder and assigned tasks when member status changes or when newsletter picklist value changes. But it’s a low volume thing so we just scan through the report once in a while.

=&2=& We haven’t yet enabled address verification but we do have a report that notices people we should be able to mail but can’t. These include donors (we try hard to have mailing addresses for all donors) and print newsletter subscribers. The report notices those people who have incomplete addresses (missing street or city). We fix these as a development task. A separate report notices people who have incomplete addresses that can be fixed — city without state or zip; zip without city or state. We regularly fix these items as an administrative task.

=&3=& When a letter comes back to us, we correct the address if a forwarding address has been provided. If no address is provided, we remove the street address. Removing the street is enough to keep up from doing future mailings. We don’t remove them unless they ask. Often we find the address again after some time.

=&4=&When someone asks to be dropped, we change the status from “completed” to “asked to be removed.”

When we notice that we cannot reach someone who subscribed to our print letter, we add them to our email version if we have email address. This might be a risky step but it’s a rare thing anyway.

=&5=&This is what we do each quarterly. I have a HOW TO folder of documents and sending the print letter is one of them. Here are the steps that involve Salesforce:

  1. Run the report on people who signed

 ...  read more