Organizing types of contacts/accounts in CRM

(1) Share

Report

Posted on by awalters

3,079

We're just starting to review our system to move to CRM, and I want to make sure my head is 100% wrapped around some core things. I've read and understand the distinction between Accounts, Contacts, Leads, and Opportunities, so I'm clear on all that. Now, as a non-profit, we have Donors, Clients, and Volunteers, as some examples. Either Accounts or Contacts can be Donors. Same for Clients, and Volunteers, and so on. In fact, the same Contact could be a Volunteer and a Donor both.

So, as we look to map our current processes and data into CRM, I'm wondering how to organize and relate all of these things. For example, should Donors be an entity, and then that has a one-to-one relationship with either Accounts or Contacts? (Since Donor has a number of parameters associated with it that are specific to being a Donor such as donation frequency, preferences about how to receive receipts, etc...) What would the parent/child setup of that look like, or would there even be one? It feels like Donor should be the child, since if the Account name changed the Donor name should change, for example, but can an entity have two parents?

*This post is locked for comments

I have the same question (0)

All responses (19)

Answers (1)

Suggested answer

ScottDurow 21 on at

Like (0)

Report

Hi,

There are number of options depending on your scenarios - but generally you would always use the account/contact to represent the various people/organisations.

1. Often the account/contact entity would have a type attribute that specifies if it is a Donor or a volunteer. This field would then be used to show/hide other fields on the form that are specific to that type.

2. If an account/contact can have more than one type, then the types can be added as boolean flags that again show/hide other custom fields.

3. If your data model is sufficiently large you may need to partition the data into sub entities (or for other security related reasons) where you would have a N:1 relationship between the Account/Contact and your Donor/Volunteer entities. When you mark that record as being one of those types you would automatically create a record and relate it to the account/contact via this lookup (using a real time workflow) and then show this field. The user then must click on the lookup to show the specific fields for this type of record. You would not store the name fields on these 'child' entities - since it is already on the account/contact.

Hope this helps,

Scott

Was this reply helpful? Yes No
awalters 3,079 on at

Like (0)

Report

Hi Scott;

Thanks for the response. There are a number of these different contact or account types, and each of them has a number of different fields. Plus as you say, there are potentially security things around this, especially for donors. So I think that we'd fall into that #3 point. Would it be N:1, though? I think each Donor or Volunteer record would only have one corresponding Account or Contact record...can't think of when/why it would be more than 1.

So there's no problem with this new sub-entity being related to either Account or Contact? I guess it makes sense that the name wouldn't be stored there, but from what you're saying it would still be a child relationship, right? And it's okay if the parent can be either Account or Contact?

Are there any existing entities like this that we could use as a model/guide, do you know? I'm reviewing the entity diagram right now, but it's pretty dense. :-)

Was this reply helpful? Yes No
Suggested answer

ScottDurow 21 on at

Like (0)

Report

Hi,

I suggest a N:1 from Account/Contact to Donor (for example) to make it simpler for the user and so that you can show related fields from the Donor entity on views of Account/Contacts. To make use of cascade features like re-parent and re-assign you also might want to have a 1:N as well which is kept in sync behind the scenes. Basically you are trying to create a 1:1 but CRM does not support this kind of relationship.

There aren't any of these pseudo 1:1 out of the box. The closest I can think of is the User->Mail box relationship.

Hope this helps,

Scott

Was this reply helpful? Yes No
awalters 3,079 on at

Like (0)

Report

I think I mostly understand this? :-) I think this is the point where I have to take this info and just try it out, and then it will become more clear as I dive in. Will report back. Thank you!

Was this reply helpful? Yes No
Verified answer

mscrmba on at

Like (0)

Report

Hi Awalters,

A Contact can be a donor, a volunteer, a sponsor contact, a board member, a committee member, a member, even an individual sponsor or have other roles with your organisation.

An Account may be a donor, a volunteer provider, a sponsor, a supplier, a programme partner. An account could represent a business, a corporate, another charitable organisation, a community group, a government organisation, a school or even a household. (You could have an Account Type field that allowed you to categorise these.)

This information is best all stored on fields on the OOTB Contact and OOTB Account records. (Holding this categorisation data on the Contact and Account records means that it is easily available for campaigns and reporting.)

Then those Contacts and people associated with Accounts interact with you - send you emails, you might meet with them (appointment), you may send them a letter - that is what Activities are for.

* I have set up a Custom Activity type called Volunteering Activity for some charities, that allows them to track who has made what time commitment to their organisation. This can be useful for statistical reporting regarding level of community involvement.

What you set custom entities for are the parcels of things you want to track/group (each of these can be linked to a primary Contact, possibly a secondary Contact and/or an Account e.g. 1 Contact:N Annual Memberships, 1 Account: NSponsorships):

* Annual Membership (if you need to track some form of formal paid-up membership)

* An Event (which you might consider using OOTB Campaign for - Event is one of the categories of a Campaign)

* A Commitment to make a Regular Donation (which might have a 1:N relationship to the Financial transaction)

* A Sponsorship (which might have a 1:N relationship to the Financial transaction)

* A Programme - something your organisation delivers into your target community(which could have relationship links to campaigns, sponsorships, events, financial transactions etc)

* A Financial Transaction (which could have a category of Donation, Regular Donation, Sponsorship Invoice, Product Sale, Membership Dues etc), which you might consider using the OOTB Invoice entity for)

You might use the OOTB Opportunities to capture,organise and manage fundraising opportunities (and even volunteering applications).

You might use the OOTB Cases to manage brand abuse, public complaints, feedback, suggestions, advocacy topics etc.

Was this reply helpful? Yes No
awalters 3,079 on at

Like (0)

Report

Some great info, and made me think about some OOTB entities in new ways. Thank you!

Was this reply helpful? Yes No
awalters 3,079 on at

Like (0)

Report

Okay, so I'm experimenting with having a Donor entity with relationships like you describe. (I'm not ruling out putting all of these things in the Account/Contact entities, but it's a lot of options/conditional fields/field level security, and it feels like separate entities may be cleaner from a maintenance standpoint in the long run.)

- I've created the Donor entity, created a 1:N relationship to Account (referential only for now), then repeated that from Donor to Contact.

- I've made a Donor Type field that asks whether the donor is a person or organization

- I've made Donor Name fields, one for Account and one for Contact, that are lookup fields to those entities.

- I've set the appropriate Donor Name field to show based on the Donor Type response.

(I'm not working on the relationship back the other direction yet, as we haven't figured out how we want this info to cascade, exactly.)

All of the above seems to work fine. However, there's the built-in Name field that was created when I created the entity. I couldn't set it as a lookup field, so it seems useless to me. This is why I've attempted to replace it with the two Donor Name lookup fields I created. I've made the field optional, and I managed to figure out how to hide it on the form. But I can't *remove* the field, or remove it from the form.

1. This seems like it will be potentially very confusing in the future (to have Name and DonorName fields), despite hiding the one and putting an explanation in the notes.

2. The fact that I'm not allowed to remove it makes me wonder if there's any major consequence in not using it. Perhaps I should make a rule that populates it in the background with the contents of the Donor Name lookup field?

Or am I totally off base with how this should be working?

Was this reply helpful? Yes No
awalters 3,079 on at

Like (0)

Report

Ah - Just found the consequence. The new_name field is of course what's shown on the default views and whatnot. So automatically populating it with the contents of the lookup field seems to be the way to go. Anything wrong with this approach (other than the fact it's a bit complicated to set up...)? :-) Thanks again!

Was this reply helpful? Yes No
ScottDurow 21 on at

Like (0)

Report

That sounds like you are on the right track - you can automatically generate the name field when it is joined to the account. Mostly I would have thought you would be referencing the account/contact rather than using the donor entity.

Was this reply helpful? Yes No
mscrmba on at

Like (0)

Report

It's not hard to auto populate. Just create 2 real time workflows and you can put the details of whichever fields - e.g. Full Name or Account Name into the Donor Name field.

You may want to make both the Account and Contact lookups on the Donor form business required (so the + button on your subgrid of Donors on the Contact and Account works OK (if you're going to have one of those). You can then make both fields optional when you open the form by using business rules.

You can hide the Name field on the form by creating a Tab (normally I put this at the bottom of the form), making that tab default hidden, and putting the name field on that tab.

Was this reply helpful? Yes No