Guidelines for checking "Contact" box on Relationship records

Daniel Noga 2

Hello everyone,



I am doing some cleanup, adding desired Attributes to some Relationship records. The purpose is to help with pulling our Annual Report list next year (it took way too long this year and much cleanup is needed).



I'm inclined to steer away from using the Contact Type field at all. I don't like that it's a one-to-one field, because the real world just won't cooperate with that vision. I feel like there are more exceptions to it than records that fit within its structure. If we have any organizational contacts, more likely than not, that one person is our main liaison for everything, in which case it's pointless defining a Contact Type. Either that, or we have multiple Contacts, but the relationships are still more fluid and nuanced than "You're our Dinner person and you're our Poker person." So we're sticking with Attributes for the one-to-many functionality.



Since I don't plan on ever needing to pull a Contact Type, the question arises: How to use the Contact checkbox? If I'm pulling lists by Relationship Attribute, then having that box checked should have no bearing on whether or not a record pulls (unless I make that a criterion), correct? If that's true, then my current thinking is: If you have one of our mailing Attributes in your record, or if we solicit your organization and you are the person we call, then you're a "Contact." Otherwise, you merely have a Relationship with us. Am I overlooking a good reason to check this box?





 

JoAnn Strommen

Do you run or think at some point in the future you will run Mail functions and want to pull/print contact name with org?  To pull names the most efficient way into mailings, I believe you would need the contact box checked.  Not sure if you can pull using relationship attribute as it's not something I've attempted.  That would be the first thing I would check out.

Daniel Noga 2

JoAnn Strommen:

Do you run or think at some point in the future you will run Mail functions and want to pull/print contact name with org?  To pull names the most efficient way into mailings, I believe you would need the contact box checked.  Not sure if you can pull using relationship attribute as it's not something I've attempted.  That would be the first thing I would check out.

Interesting question. In the past, I stuck to Mail religiously when pulling mailing lists since that's what the module was designed for, and back then, it really did matter if that box was checked. I'd forgotten, because I prefer Export now for the flexibility it offers. That being said, I've learned that there's a reason Mail is called Mail, and there are things you can do with it that you can't with Export. I'd have to really think hard as to whether or not that will be important for us in the future. Thanks for bringing that up, I wasn't even thinking about Mail.

JoAnn Strommen

Follow-up question - how is this related to pulling your Annual Report list?  I think I'm missing something.

Daniel Noga 2

JoAnn Strommen:

Follow-up question - how is this related to pulling your Annual Report list?  I think I'm missing something.

This is for our Annual Report mailing list, not the donation listing--I should have been more clear about that. Some of our most important recipients of that come through Relationships to organizations that give big, and do not have Individual records of their own. They are the ones I want to make sure are coded like the dickens.

Gina Gerhard

One other consideration when marking contacts: When you're searching for organization records, one of the options is 'Check contact name'.  If you don't have anyone checked as contacts, they won't be scanned when doing your search.



Since the Contact Type function is essentially 'one-dimensional', we ended up using it for the most broad/general way we relate to the organization - which is for broad mailing purposes.  So typically, we'll have the President or Executive Director as the primary contact with the type 'Primary' (we try to keep this as 1 selection), additional contacts typed as 'Secondary' (1-3 additional), and others we want to be considered in searching on a record as 'Other'.  For most broad mailings, we'll pull in the Primary and may also choose to mail to Secondary contacts in some cases.



For more specific and other types of contact typing, we use relationship attributes which you can then include using Address Processing in Export to pull into your lists.

Daniel Noga 2

Gina Gerhard:

One other consideration when marking contacts: When you're searching for organization records, one of the options is 'Check contact name'.  If you don't have anyone checked as contacts, they won't be scanned when doing your search.



Since the Contact Type function is essentially 'one-dimensional', we ended up using it for the most broad/general way we relate to the organization - which is for broad mailing purposes.  So typically, we'll have the President or Executive Director as the primary contact with the type 'Primary' (we try to keep this as 1 selection), additional contacts typed as 'Secondary' (1-3 additional), and others we want to be considered in searching on a record as 'Other'.  For most broad mailings, we'll pull in the Primary and may also choose to mail to Secondary contacts in some cases.



For more specific and other types of contact typing, we use relationship attributes which you can then include using Address Processing in Export to pull into your lists.

I like this way of organizing things. I think I will model our coding structure after this. I am also thinking of setting a policy that everybody with the Contact box checked should also have a Contact Type, a Relationship Attribute, or both--something to back up why they are considered Contacts. This can be something sent around regularly for review by our development staff for updating. This way, we might prevent many cases of sending things to people who aren't at the organization anymore, or people who don't necessarily need to get a given mailing even though we want them logged as a Relationship.



Something else that occurred to me this morning: As an admin in RE:, I sometimes forget what users see on their screens when they pull up records. There may be reasons to use a Contact Type just so people with lower security clearances can make more sense out of the records they're looking at.