web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

No record found.

Community site session details

Community site session details

Session Id :
Microsoft Dynamics CRM (Archived)

Good ways to deal with families/households

(0) ShareShare
ReportReport
Posted on by 3,079

We have a number of contacts with familial relationships, and need to track these for the following reasons:

1. Addressing letters, printing mailing labels, etc...

2. Tracking donations or volunteer hours from all members of a household

3. Targeted communications to household "decision makers"

As far as I can tell, I can track these by using Connections, or by creating a Contact hierarchy, or by using Accounts as families.  

We would prefer to not do the last one, since we're already using Accounts as organizations, which have very different functions in our business workings than Contacts.  Which leaves Connections or a hierarchy (or am I missing an option?  I suppose a custom Household entity is another option, but again we'd really like to keep these with the Accounts - if we want to print mailing labels for example, it's a mix of Accounts and Households, which obviously gets more difficult if those are in different entities).

I'm trying to think through all of the ramifications of doing either of these approaches.  For certain types of communications, we just want the family in the list one time rather than once for each.  So if we use Connections I'm not sure how those filters take place.  Also, can you do rollups across connected records?

But if we use a Hierarchy, how do we deal with two parents?  I can't find a way to do that.  Rollups should be easier, though...

Do other people have this scenario, and how are you handling it?

*This post is locked for comments

I have the same question (0)
  • MEinKC Profile Picture
    on at

    Hi Allison. I just implemented a CRM system for a nonprofit client which had a similar scenario. We do have their families as Accounts and added an Account Type of "Family" as well as using Family in the name. Since CRM has out of the box relationship with Contacts, all members of this family are connected without any additional Connections needed. You can certainly use connections to connect your "Decision Maker" contact to the family account by simply choosing that as your connection role and then you can use Advanced Find to build a query on just your Decision Makers.

    To track volunteer hours, we added a custom entity for a "Volunteer Log" with a lookup to the Contact since they don't need to track at the family level. But you can also add the Account to this as well. This will establish a relationship between both entities. Then you should be able to add a subgrid to your Account and/or Contact form and choose the related entity of "Volunteer Hours" to show those related records.

    Hope that helps with part of your questions.

    Cheers,

    Michelle

  • awalters Profile Picture
    3,079 on at

    We've renamed Accounts to Organizations since that's how it's being used 95% of the time and that's the usual wording.  So it would definitely be highly confusing to have households there as well, unless we changed the wording again (which wouldn't be intuitive to any).  So that's a big concern for me, but not entirely a dealbreaker.

    However, if your org wants to print letters or mailing labels for all individual (i.e. non-corporate) donors, if households are Accounts don't they now have to go to two places to do that?  (As one example of how the cross-entity interaction makes me wary)

    Also, how are you dealing with the donations in that scenario?  Does the donation get credited to the Account or a Contact under the Account?

  • MEinKC Profile Picture
    on at

    You could certainly create a custom entity for Households; however, there is some benefit of using Accounts over a custom entity and that is primarily that a lot of your relationships and fields are already established to the Account entity. If you add a custom entity, you have to establish all of those yourself. If all it comes down to is semantics (Organizations vs. Households), I can only advise to think about how CRM is already setup because it might save you a lot of time over building out custom functionality. Perhaps your users could simply adjust to a Household being under "Organization"? Create a form to enter Households if you need to capture a lot of information that is different from a corporate organization.

    I'm not sure I understand your question about the letters and mailing labels? Are you talking about using Advanced Find to build your query and exporting or mail merge?

    Donations in our case can come from a corporate partner (Account), a family (Account) or an individual (Contact). We are using invoices to track our donations because we are also integrating with GP. The default "Customer" field on the Invoice form is a special lookup that lets you choose an Account OR a Contact. Whatever you choose here is what the Invoice record gets related (or credited) to. This would be another benefit of using the built-in Account entity should you handle donations through invoices so you can choose either an Account or a Contact in one field.

  • awalters Profile Picture
    3,079 on at

    We are planning on using Invoices as well, yes.  But we can't have a household get chosen as the "person" donating - by CRA rules individual donation tax receipts must be made out to a single person, not a household.  So if we had households as accounts we'd need to filter those out so they couldn't be selected - don't know how we'd do that.

    As for the letters and mailing labels - I was talking about a Mail Merge, yes.  I haven't really tried them yet, but everything else in CRM seems to be *vastly* complicated when you try to span across entities (or impossible, in the case of views) so I assumed those would be adversely affected as well.

  • awalters Profile Picture
    3,079 on at

    Another question is the difference between a physical household (i.e. everyone at the same address), and a family unit (tracking parent/spouse/child relationships), as these aren't necessary identical...

    Hmmm.  Talking about this more internally, it looks like tracking the relationships is more important than tracking the physical household.  The only time the physical household comes up is for the mailouts, and we apparently do exceptionally few of those.  Few enough that probably just flagging duplicate addresses for some manual tweaking would be okay.  So - the reason to track the relationships would be to deal with tracking totals when multiple people from a family donate, and for targeted communications.  I feel like Connections would be sufficient for the targeted communications, but I'll have to test that.  The donations are trickier, since we wouldn't be able to roll up across family members.  But maybe we use soft credits instead?

    I may be missing advantages/ramifications here, though, since we're not that far into the process.  Can I ask, what are your advantages to having households be accounts?  It sounds like one is allow the household to be selected as the donor, which isn't an option for us due to CRA receipting requirements.  Another one is to connect the family members, but how do you indicate who's the parent and who are the children?  Job titles?  Are there other advantages as well?

    Thank you!  I appreciate the time; so many CRM implementations are obviously sales/customer service focused; it's lovely to get more perspective from someone who's done a NFP implementation.

  • MEinKC Profile Picture
    on at

    I definitely understand having to differentiate a household vs. a family unit which can be split across multiple addresses. Really, you could handle that in a couple of ways - having ONE primary household account that is used as the main mailing address and contact information. Or, having a parent household account and you can have a child account tied to that if parent's are divorced and what not. Really many ways you could handle doing that.

    Having households as accounts really does come down to an easier way to track those relationships and establish a primary address and contact information when you want to communicate at the family level. My client also had cases where parents are divorced or children are adults, and those simply get their own addresses and such  entered into their contact record, but remain linked to the family. The family holds the membership 99% of the time. It was important for us to keep everything linked up around their client, which is typically a child. Households let us keep all family members together, including siblings and such. You absolutely could choose to not have a household account and only have individuals as contacts then relate them through connections.

    I suggest using Connections to establish your familial relationships and just setup/choose the applicable connection role for the relationship - mother, father, spouse, child, etc. You will want to add the Connections subgrid to your Contact forms so on each person's record, you can see a list of their family connections. Connections are pretty awesome in my opinion and you can search on those relationships using Advanced Find and add them as columns to your views so you can sort, filter, export based on these connections.

    For your invoices, if you don't want users to be able to select Accounts at all in the Customer field, you could add a lookup field to your Contacts and I would then make your Customer field read-only or hidden. You can then setup a business rule or workflow to populate the Customer field with your chosen Contact. The Customer field is a system field and it is required - you can't remove it or edit the lookup function to both Accounts and Contacts so your best bet is to just make sure people can't click on it to enter data -- just populate it for them.

    You're very welcome for the advice. My opinions are just one way of doing things. CRM is super flexible so there might be better options for you. I know NFPs face a very distinct set of needs and challenges!

  • awalters Profile Picture
    3,079 on at

    We do need people to be able to enter Accounts for donations, though, since we get donations from companies.  It just needs to be either companies or individuals, not households.  Not sure I know a way to block out just household if they're accounts, but not other accounts....will have to ponder.

    It sounds like your organization is more focused around family units (with children as the org's clients, having memberships, etc...) and therefore likely has a stronger need to have the physical groupings tracked than we do.  For us, our clients are generally organizations, and individuals are donors or volunteers.  The physical info is good for mailouts, but I'm told we only do one or two of those a year at most (yay!  I actually really dislike when I donate to a charity and then start getting large amounts of things in the mail - that's expensive!).  So yeah, I'm leaning more and more towards Connections.  However, I haven't yet figured out if I could do a rollup field across Connections.  Looks like not, but still playing around.  That's not 100% necessary, but it would be nice to know how much a couple has donated together, for example.  We'll likely end up using soft credits for this, but just want to think through all the implications first.  :-)

  • awalters Profile Picture
    3,079 on at

    So - only one other person deals with households?  :-)  I assumed this was not an uncommon issue that people had faced, and was curious to hear the variety of solutions, but...does it just not come up for most people?

  • ThomasN Profile Picture
    3,190 on at

    Hi Allison and Michelle, this is an interesting discussion and grateful for you both sharing on here for myself and others to learn from. I am responding to the interest in others having a similar problem. The discussion of connections, roles, and hierarchy comes up in every implementation. That is why Microsoft added the Hierarchy feature. I have done complex role development with a rich lexicon defining the different relationships and they were just not used as expected.

    I have learned over time to be wary of the "nice to know" vs. the "need to know". The best way to discover the difference is to take a break from the requirements discovery process and ask the question "When was the last business decision made using this data?" If the data did not exist then "What business decision, or strategic goal would we advance if we knew this information?", "How often would we pull it, who would be the data steward to maintain and audit these relationships?", etc.

    Every time a project has answered those questions honestly for connections the requirement has gone away. The amount of effort needed to implement does not provide the benefit expected. I am excited for you and your organization and hope the connections work well for you.

    Please read with kind intent, I do not mean to seem so cynical. I really believe connections could provide benefit, just have not seen it yet. Account/Contact relationship has always been enough, in Higher Ed., Healthcare, Consulting Services, and Auto Industry. But Non-profits are a different animal.

    Have a wonderful day!

    -Tom

  • Community Member Profile Picture
    on at

    Allison, I have found your discussion really interesting as I am also investigating best ways to deal with house-holding in a NFP implementation. Have you seen msdynamicsworld.com/.../managing-complex-relationship-models-microsoft-dynamics-crm-part-1. I found that useful too.

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Neeraj Kumar – Community Spotlight

We are honored to recognize Neeraj Kumar as our Community Spotlight honoree for…

Leaderboard > 🔒一 Microsoft Dynamics CRM (Archived)

#1
SA-08121319-0 Profile Picture

SA-08121319-0 4

#1
Calum MacFarlane Profile Picture

Calum MacFarlane 4

#3
Alex Fun Wei Jie Profile Picture

Alex Fun Wei Jie 2

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans