We recently collaborated with an organization who does highly-effective therapeutic work with at-risk children in the Seattle area. Children served by this organization often have a complex web of caregivers, relatives, foster parents, siblings, half-siblings, case workers, and other significant people in their lives. These children frequently change living situations. It is critical for this organization to have an accurate and detailed view into each current and past child’s familial and living situation, as well as a way to update caregiver and household information as it changed.
For example, consider this information that needs to be tracked about an enrolled child:
- Jen Goodkid’s biological mother is Maddie James.
- Jen used to live with Maddie, but now lives with her grandmother and aunt.
- Jen, her grandmother, and her aunt recently moved to a new location.
- Jen’s biological father is Jack Jones, who is currently barred from contact with her.
- Jen has a half-brother named John Sweetkid who is also enrolled in the program.
- John lives with Jack.
- John was previously in foster care with the Smith family.
- Jen and John have a caseworker in common.
- Jen used to have a different caseworker.
Whew! It may seem like a lot of detail, but it’s all key information for this organization. So, how to keep track of all this and view it in a clear and useful way? The organization needed to look at Jen Goodkid’s record and see at a glance who was in her life, as well as view from Jack’s Contact record his relationships with his kids.
Enter the Nonprofit Starter Pack. We were able to make use of the built-in NPSP Household and Relationship functionality to get us about 80% of the way there. The remainder took a combination of some custom fields, configuration, and process builder flows to keep the information we needed in sync.
Households – who lives with the child?
We started by working with the organization to clarify requirements and definitions of family and household. We also determined which staff within the organization needed to see the information in which ways. It turned out that the NPSP’s Household Account model and functionality matched up nicely with the way the various staff needed to view a child’s living situation. It allowed us to:
– group related people at one address
– add or remove people from an address
– update the address of the household if the entire family moved
In Salesforce, here are the Household members living at the same address:
One thing that did NOT come out of the box was a way to automatically exclude the child’s name from the Household name, which was one of the organization’s requirements. The NPSP does have a handy feature that lets you edit a Household and indicate any Contacts whose name you want to exclude from the Household name, but the staff at the organization didn’t want to manually edit every single Household Account record.
To meet this requirement, we created a Process that fires on Contact creation and update. If the Contact was a “Child” type of Contact, and was in a Household with more than one member, the process set the “Exclude From Household Name” field on the Contact to TRUE. Voila! Households were taken care of.
Relationships
Then it was on to the more complex issue of accurately capturing and viewing the various relationships that are typical for the kids enrolled in this organization’s programs. The NPSP’s Relationships package allows you to configure a relationship between two Contacts, and specify the type of relationship, such as aunt, parent, case worker, etc. It also comes with a “Status” field which you can use to indicate if the relationship is current or not. So far so good. But this organization also needed additional information: was the adult in the relationship a primary caregiver, either currently or previously? Was there a No Contact order for this particular adult?
We decided to use the NPSP Relationship “Status” field as intended, to indicate if the relationship itself was current or past. This made sense in cases where the relationship could potentially end, such as relationships between kids and foster parents, or between kids and case workers. For biological relationships, the status would always be “current.”
To track the additional information about Primary Caregiver and No Contact status, we configured two custom fields on the Relationship object, and added them to the Relationship layout. Then staff could create the appropriate Relationship records between Contacts, and see Jen’s relationships at a glance:
But wait, not quite done
The staff also wanted to click on Jack Jones, and see the relationships between him and his two children. This was what we got with the NPSP Relationship functionality out of the box:
Oops, the values in our custom fields, Primary Caregiver and No Contact, didn’t carry over to the Reciprocal Relationship for Jack Jones. To deal with this, we created another Process that copied the values from our custom fields over to the Reciprocal Relationship:
Once this Process Builder was activated, the staff was able to view accurate relationship information from Jack’s Contact record:
Relationship Viewer
One more handy feature for visualizing complex relationships comes out of the box with the NPSP: the Relationship Viewer. This feature graphically displays any configured relationship between Contacts:
Conclusion
Through the use of custom fields and Process Builder, we were able to extend the core functionality of NPSP relationships and Households to track complex relationships. This is allowing the organization to be able to take better care of the kids in their program. Through improved tracking, they can improve their outcomes, and spend more time focused on helping improve kids’ lives.