Constituent Code End Dates

Options
Hi Brilliant Community Members! My question today is about Constituent Code end dates. As database admin, I have used start dates and end dates on Constituent Codes and have never had a problem with them. I have heard others say that you shouldn't use end dates because they may drop constituents off of canned financial reports. Since I did most of my financial reporting in Crystal or Excel pivot tables, I have never had a problem. I would love to hear your take on why one should or shouldn't use end dates for Constituent Codes. Thank you for sharing your knowledge and experience. 
Tagged:

Comments

  • Thank you thank you thank you
  • Hi Jill-

    I would take Bill's answer in that PDF one step further. If a constituent has multiple Constituency Codes, some with populated To Dates, and you use Export to view each of those codes, but you forget to populate the Date From field in Export before running it, you may get unintended results and see Constituent Codes that are no longer active. See my comment about Export here. This may not be an issue for Crystal depending upon how you've designed your report, but it is an issue with Export.


    For this reason, I maintain only one Constituent Code on each record indicating that constituent's relationship to us TODAY. All historical Constituent Codes are tracked through relationships to organizations (Board relationship dates when Board becomes Former Board, Staff relationship dates when Staff becomes Former Staff, Parent relationship dates when a Parent becomes Former Parent, etc...)


    I also do this because if someone has more than one active Constituent Code (say Parent and Board) and you run a Gift Detail and Summary report looking at Parent giving and then the same report looking at Board giving, you are going to count that money twice (assuming you are reporting on Constituent Constituency Code and not Gift Constituency Code). Add to that if a constituent has two active codes (Board and Parent) and someone else is entering the gifts, what's to stop the gift entry person from placing the Parent constituency on one gift and a Board constituency on the next gift?

    There are many other solutions, but this is how I've decided to manage the data.


     
  • Dariel Dixon 2
    Dariel Dixon 2 ✭✭✭✭✭
    Seventh Anniversary Facilitator 4 Name Dropper Photogenic

    For this reason, I maintain only one Constituent Code on each record indicating that constituent's relationship to us TODAY. All historical Constituent Codes are tracked through relationships to organizations (Board relationship dates when Board becomes Former Board, Staff relationship dates when Staff becomes Former Staff, Parent relationship dates when a Parent becomes Former Parent, etc...)

    I also do this because if someone has more than one active Constituent Code (say Parent and Board) and you run a Gift Detail and Summary report looking at Parent giving and then the same report looking at Board giving, you are going to count that money twice (assuming you are reporting on Constituent Constituency Code and not Gift Constituency Code). Add to that if a constituent has two active codes (Board and Parent) and someone else is entering the gifts, what's to stop the gift entry person from placing the Parent constituency on one gift and a Board constituency on the next gift?

    There are many other solutions, but this is how I've decided to manage the data.


     

    This is an interesting take.  There are many times where a person will have multiple concurrent constituencies. For example, lets say at a school, you can have a alumnus that now works at the institution.  Therefore, they could have the codes of alumni and possibly Faculty/Staff.  In regards to VSE and other reporting, your position is very valid, however I think that both constituencies are worth keeping on a record.


    Also, in regards to this same example, do you think that assigning different gift constituencies to gifts from the same individual is a bad thing?  I don't know if I do.  If the hypothetical employee gives to both the annual alumni appeal and the f/s appeal, would it be acceptable to assign the appropriate constituencies to a gift?

  • JoAnn Strommen
    JoAnn Strommen ✭✭✭✭✭
    Ancient Membership Facilitator 4 Name Dropper Photogenic
    We also have records with multiple open constituencies. For gifts, we select the appropriate constituency. If this is entered on gifts, I can pull any reports needed or just report on primary constituency.


    Dariel, yes, I have used different ones for different gifts.
  • |> This is an interesting take.  There are many times where a person will have multiple concurrent constituencies. For example, lets say at a school, you can have a alumnus that now works at the institution.  Therefore, they could have the codes of alumni and possibly Faculty/Staff.  In regards to VSE and other reporting, your position is very valid, however I think that both constituencies are worth keeping on a record.


    True, but there's no requirement that says all relationship data should be loaded in a Constituent Code. I understand this is common practice, I'm simply pointing our there are ways to double-count data or display erroneous data if you don't understand the potential pitfalls to multiple Constituent Codes on one record. Knowing someone is an Alumni and a Staff is important for the VSE, but you cannot count the same person twice and you cannot count the same gift twice thus my concern with using multiple Constituent Codes. You'll have to make a choice one way or the other so, in this specific case, having both Constituent Codes on the same constituent record doesn't help, it adds confusion.

    |> Also, in regards to this same example, do you think that assigning different gift constituencies to gifts from the same individual is a bad thing? 


    Yes, I do. If I want to report on Board Giving and half of my Board donations have the Gift Constituency Code of Board and half have the Gift Constituency Code of Parent, it's going to take me some extra work to undo the whims of the gift entry person. Consistency in data entry is key. I think we can agree on that.
  • Dariel Dixon 2
    Dariel Dixon 2 ✭✭✭✭✭
    Seventh Anniversary Facilitator 4 Name Dropper Photogenic

    Aaron Rothberg:
    |> This is an interesting take.  There are many times where a person will have multiple concurrent constituencies. For example, lets say at a school, you can have a alumnus that now works at the institution.  Therefore, they could have the codes of alumni and possibly Faculty/Staff.  In regards to VSE and other reporting, your position is very valid, however I think that both constituencies are worth keeping on a record.


    True, but there's no requirement that says all relationship data should be loaded in a Constituent Code. I understand this is common practice, I'm simply pointing our there are ways to double-count data or display erroneous data if you don't understand the potential pitfalls to multiple Constituent Codes on one record. Knowing someone is an Alumni and a Staff is important for the VSE, but you cannot count the same person twice and you cannot count the same gift twice thus my concern with using multiple Constituent Codes. You'll have to make a choice one way or the other so in this case having both Constituent Codes on the same constituent record doesn't help, it adds confusion.

    |> Also, in regards to this same example, do you think that assigning different gift constituencies to gifts from the same individual is a bad thing? 


    Yes, I do. If I want to report on Board Giving and half of my Board donations have the Gift Constituency Code of Board and half have the Gift Constituency Code of Parent, it's going to take me some extra work to undo the whims of the gift entry person. Consistency in data entry is key. I think we can agree on that.

    Excellent...I love these responses.  You make great points.  I agree with the fact that relationship =/ constituency.  It is a common misconception, but I agree that not every relationship needs a code.  The biggest issue I have with it is simply on times when you have to report on one or the other, if I decide that I'm only keeping one of the codes, how do I make sure that I count those gifts when reporting on the other?    


    Everyone here agrees that double counting is a BIG problem, and your solution seemingly solves that.  Props to you and your solution.  I just am thinking that reporting on gift constituency vs. constituent code is also an option.  That's what made me ask the second part.  I think there are times when a person would need to pull in gifts based on the individual/organization constituency, vs. the constituency on the gift.  Knowing that the gift constituency pulls from the table on the record, that's where I am thinking that having the multiple codes on the record potentially could be helpful.  However, that can also cause your code table to get out of control.


    I'm just thinking about this out loud.  I really like your idea and your implementation.  

  • I'd put it this way. If you have a parent that gave $100, a parent/board member that gave $100, and a board member that gave $100, you cannot report that Parents donated $200 and the Board donated $200. Well, you could, but I think you'll raise some eyebrows when you announce you only raised $300 in total.


    To that end, when I'm reporting on gifts I always report on the Gift Constituency Code and never on the Constituent Constituency Code. Sure, you can do it and depending upon how you data is set up you may get correct totals, but if your constituent records have more than one Constituent Code you risk double-counting money that someone else won't realize until you report total fund raising and your audience sees that total raised in aggregate is less than the sum raised by each individual segment.


    Having said all that, yes, someone in your organization will want to know what board giving is outside of any other numbers and yes, in those instances reporting on the Constituent Constituency instead of the Gift Constituency makes perfect sense and will work just fine even if your constituent records have more than one Constituent Code.


    Six of one, half-dozen of the other. Pick your poison.
  • Dariel Dixon 2
    Dariel Dixon 2 ✭✭✭✭✭
    Seventh Anniversary Facilitator 4 Name Dropper Photogenic

    Aaron Rothberg:

    I'd put it this way. If you have a parent that gave $100, a parent/board member that gave $100, and a board member that gave $100, you cannot report that Parents donated $200 and the Board donated $200. Well, you could, but I think you'll raise some eyebrows when you announce you only raised $300 in total.


    To that end, when I'm reporting on gifts I always report on the Gift Constituency Code and never on the Constituent Constituency Code. Sure, you can do it and depending upon how you data is set up you may get correct totals, but if your constituent records have more than one Constituent Code you risk double-counting money that someone else won't realize until you report total fund raising and your audience sees that total raised in aggregate is less than the sum raised by each individual segment.


    Having said all that, yes, someone in your organization will want to know what board giving is outside of any other numbers and yes, in those instances reporting on the Constituent Constituency instead of the Gift Constituency makes perfect sense and will work just fine even if your constituent records have more than one Constituent Code.


    Six of one, half-dozen of the other. Pick your poison.

    I agree Aaron.  You're absolutely right.  There is no perfect solution.  Each has its own deficiencies.  I think that making sure you know and understand the consequences of the policy is fine.  No philosophy is wrong here.  This is an imperfect science, and I think that perspective is important to note.  Either route you go, it may result in more work than we like.   


    I appreciate the conversation.  It's good to look at things in a different way.

  • Thank you so much Aaron, Dariel and JoAnn! Great and enlightening discussion! Just what I was hoping for. 

Categories