Constituent Wars Part I: How Raiser’s Edge Relationships Translate to Salesforce
In this first part of a three-part series, inspired by my love of Star Wars and the wonderful three-part series on NPSP Customizable Roll-Ups from Hayley Tuller, I will review and explain some of the key considerations for a move from Blackbaud’s Raiser’s Edge to the Nonprofit Success Pack. I won’t speak like Yoda in these posts, unless that proves to be helpful, young padawans. Get ready for the first installment in the epic trilogy that follows.
My Experience with Raiser’s Edge
As a college undergrad I completed an internship working at a nonprofit where my older sister was the development coordinator. She taught me the ins and outs of Raiser’s Edge, and I learned so much that I went on to work at several nonprofits as a database administrator. My work focused on cleaning up Raiser’s Edge data and handling the day-to-day tasks of a direct mail and online giving officer. I guess she was more like the Obi-Wan Kenobi of Raiser’s Edge and I ended up being young Skywalker. Thankfully, there was no Darth Vader in this situation.
Some years later, when I became an accidental Salesforce admin, I took this database knowledge and put it to work helping migrate data from Raiser’s Edge to Salesforce. Since I had a grasp of the Raiser’s Edge architecture from my experience as a database administrator, and had experience with how end-users used Raiser’s Edge on a day-to-day basis, I was in a unique position to help with these often complex migrations (Thanks, sis!)
How do Constituents Translate to Salesforce?
One of the main things to consider when moving from Raiser’s Edge to Salesforce is that the two basic types of constituents are separated by a key indicator field. If that key indicator is “I”, the constituent will come into Salesforce as a contact, meaning they are considered an individual person. If that key indicator field is “O”, the constituent is considered an organization account in Salesforce, meaning they’re an organization, foundation, corporation, or something of the sort.
When I prepare for a migration, I run a constituent query that separates constituents by this key indicator into separate reports for ease of importing to Salesforce. I then only include fields that are important based on that key indicator. In my organization query (constituent query with key indication = “O”) I can remove fields for first name, last name, birthdate, marital status, etc. because these will not be useful for an organization constituent record in Raiser’s Edge.
How Do I Migrate Married Couples to Salesforce?
Within the NPSP Data Model the Household account model links contacts (or constituents) together in households. This becomes helpful when you want to see total giving for a household, which rolls up the information for all contacts within that household account record.
When you create a new contact in Salesforce a household account record is automatically created at the same time. For example, if I create a contact for myself (Berkeley Baker), NPSP will automatically create a household account record for the Baker Household. I can then create a contact for my wife (Stephanie Baker) and connect her to that same Baker Household. A typical household account is shown below. Note that there are two contacts connected by a relationship within this household.
How Would I Migrate Constituents into Households in Salesforce?
Now for the sad part. Raiser’s Edge does not have a straightforward way to export information on what constituents should be migrated into the same household in Salesforce. Before you ask, using the force can’t help with this. In constituent queries and exports, if I create a query to pull out every constituent with a spouse listed (Spouse First Name not blank or Spouse ID not blank), it will pull this information out, but there will be two separate records for each person. It might look like this:
Notice that it shows up as two separate records, but we know these two should be in the same household. There’s no easy way to dedupe this information (if you are aware of a way please share) but there is a workaround I’ve come up with. This solution is contingent on having quality data in the system, especially quality relationships.
In the past I have brought every individual constituent into Salesforce as their own contact and household by using a relationship query to find all relationships with a ‘type’ of Spouse or Partner, and used this to create the households in Salesforce. You may have to clean these relationships up, but using the head of household field to indicate which contact should be the primary contact on a household account will help simply the process
Speaking of Relationships…
In Salesforce, relationships are split into two categories: relationships and affiliations. A relationship is the connection between two contacts in Salesforce, like the husband and wife relationship I described earlier. An affiliation is the connection between a contact and an organization, like how I am related to Arkus as an employee of the company.
I have found success getting relationship information from Raiser’s Edge in a few ways. One option is to create a relationship export to gather both the constituent and related constituent information. With these exports, it’s important to indicate in your criteria that it NOT pull any relationships where the relation type is blank. Another option is to create a relationship query to grab that information as well. It’s important to not only grab the Constituent ID, but Grab the Constituent Import ID for your organization records because sometimes that is a better external ID to import with, depending on your org’s RE data.
This seems like a no-brainer, but I’ve seen numerous instances of this in exported data, and you can’t create a relationship in Salesforce without knowing what the relationship is. As you may have to do some data cleanup beforehand, it’s never too early to pull these reports to see what lies ahead.
Coming Soon… Part II: How Gifts Translate to Salesforce
I really wanted to come up with a witty name for Part II that related to Star Wars, like “The Rise of Opportunities and their Record Types.” For now, all I can tell you is that we’re going to dive into gifts. Stay tuned for the title.
Are you preparing for a migration to Salesforce from Raiser’s Edge? Tell me all about it in the Trailblazer Community, or tweet directly at me on Twitter @berkeley_t_b. Subscribe to the Arkus newsletter here to get the top posts of the Arkus blog direct to your inbox.
