Lock In Your Account Data Model

I love the NPSP Household Account data model. I think it's easy to understand, pretty convenient to work with, and has stood the test of time. It takes maybe two minutes for even brand new Salesforce users to grasp that

• In Salesforce, all contacts must be on an account (for historical technical reasons that I usually briefly explain).

• In order to use Salesforce in the nonprofit context (to understand whose money a donation came from), we have the Household Account model.

• In this model we put all contacts directly on their Household Account.

• NPSP's triggers handle creating these accounts when you leave the Account field blank.

• We also have organization accounts (one record type or many) to which we affiliate contacts.

  
  

Make It Required

To keep data clean, I want to ensure that all my records stick with the household account model. So I like to have a validation rule. (You can remind people not to put contacts directly on accounts, but they sometimes forget.) The formula for that validation is quite simple:

Account.RecordType.DeveloperName <> "HH_Account"

[Remember that validation rule formulas are "backwards." The rule will fire if the formula returns "true," so you want the rule to show what you don't want to be the case.]

And I try to have a friendly message, along the lines of

Contacts should always be on a household account. (Leave blank and the NPSP triggers will create the account.) Their employer (if you want to record it) goes in the Primary Affiliation field.

Mixed Data Models

Of course, some organizations intentionally use a mixed data model in their NPSP org. Donors, board members, and anyone else we're dealing with as a "whole person" belong in the household account model. But for program participants we have no need for a household. They can just follow the standard Sales Cloud data model and be directly child to an organization account. For example, a program that runs SAT prep classes in schools can put students directly "on" the account of their school. If we have no need for household accounts for each of the students, it simplifies things.

If you're mixing data models, you can still have validation rules. One for the students (or clients or whatever you might call them):

And one for the other contacts:

Keep that data nice and clean!

Lead Conversion

Those validation rules can throw a wrench into the gears if you use (and convert) Leads. Even when you enable the NPSP lead convert override (a required post-install step) you'll get an error with validation rules like that. As best I can tell, the NPSP override must initially create the new contact directly on an organization account (or with Account blank), so you hit the validation before the conversion finishes. But four easy steps will fix this:

1. Create a formula field on Lead that returns the Id.

   

2. Create a text field on Contact called ConvertedLeadId__c. (Leave it off page layouts.)

   

3. Set your Lead conversion field mapping (Object Manager>Lead>Fields & Relationships>Map Lead Fields) to put your new lead field into your new contact field.

   

4. Add to your validation rule formula so that if ConvertedLeadId__c has a value, it won't fire.

Now when your lead is converted the resulting contact has the Id of the lead it came from in the ConvertedLeadId field, which can be helpful at times. But most importantly your lead conversion won't hit the validation rule!