Hello everyone,

 

We have very specific constituency codes and every year, there are certain constituency codes that we have to change. We change new parents to current parents, grandparents to former grandparents, current students to alums and so on and so forth.  We don't like to use the dates associated with constituency codes (date from and date to). Other than running static queries and reports listing these people before we change the codes, is there any way to keep track of when the constituency code was changed? A way to know when a current parent was a new parent? We would like to have more than just a note in their record - something that can be pulled up in a query.

 

Thanks for all of your thoughts and ideas!

The only reasonable place to record this information is the obvious place:  the "date from" and "date to" fields.

Drew

  I understand what you are saying. However, because we use multiple constituency codes (for example, a person may be board and current parent) and do not keep old constituency codes (for example, an alum does not also have a current student code), we need a way to look back and pull when a constituency code has changed. Is there a way to pull this info. in a report or query?

We have similar constituency codes changes that we make yearly, but I don't know if our solutions will work for you.

We use an Attribute to record the first year a family attends school.

Current students exist as relationships for their parents and grandparents. They get their own records when the become Alums. For all of these relationships, we use the Education tab to record the Class of, Date entered, Date left, Date graduated, and Status (Graduated or Left).

So, I don't suppose we've ever really needed to research when a grandparent became a former grandparent in a query, but we can look up individuals by checking their relationships. 

Sorry this is coming so late, but I hope that it helps. 

We also change constituency codes for New Parents, Parents, Grandparents, Former Parents/Grandparents, etc.

A donor can be more than one constituency code as well. 

I agree with Drew.  The only real place to keep that information is by using the dates.  I guess my question would be; why don't you like to use the dates? 

My new parents are also coded as parents.  Since my codes all changed over the summer, I can run a query of my 07-08 New Parents by  saying constituency code = parent and date from is between 09/01/07 and 06/30/08.  That will include all parents that came at the beginning of the year and those that came in the middle of the year. 

Our issue with the dates is that when they become a Former Parent - we lose that information (at a glance anyway) - we have to dig if we want to know when they came to our school, but we know at a glance when they left/they son graduated. 

 Hope that helps.

Heidi

 

Hi Emily,

I, too, haven't been comfortable with using the date ranges. I found out that when running statistical report by consituency code if a donor such as a past parent who has a constituency code date range ending prior to the current FY, they are listed as "Unknown" constiuency code on the report since RE considers them no longer valid as that constituent code. So we made the decision to remove all the dates and code all new incoming parents with an attribute "New to Milton" when they first become parents and the attribute table is populated with all the FYs. So then we are able to query on attribute=New to Milton=FY06-07 and also show that field on parent phon-a-thon forms. 

This solution works for us since we rarely need to query on exact dates someone was a certain consituency code (except for former trustee terms which we do code with dates). This works for us -hope it helps!

 Kate

Typically when date ranges do not work for you is when they are not used properly.  If you add an end date to a constituency code and do not add a code to be used after that date range is over then the system will report on it as Unknown.  By adding a date range you are saying "only count this person in this constituent code during this date range"  If you give the system nothing to use before or after those dates then that is a data entry error.

So if you have a constituent who was a parent between 9/1/2004 and 5/30/2008 you will have to enter a new constituency code for the system to use beginning on 6/1/2008.  RE does not have or create an automatic "former parent" code.  If you want a former parent code then you create one and add it to their record with a date beginning 6/1/08.  You also have the option of setting them back to friend or individual or whatever you use for non-parent constituents.

Essentially if there is no active code during any date range on a record and you try to use some of the reports which use constituent codes and date ranges it will report as Unknown which is probably not what you want.

I agree with Melissa.  When a relationship ends, you need to code two pieces of information:  the fact that the existing relationship has ended and what the new relationship is.  If you are simply entering "To Dates" on the existing relationship, you are only entering half of the information.

Maybe an example would help.  My current job is at a hospital, but my last job was at a university that had a medical school.  Both organizations have medical residents and medical fellows, but they treat former residents and fellows differently.  The university rightly feels that former residents and fellows don't have as strong a connection to the university as people who did their undergrad, graduate, or professional degree at the university.  They have a separate constituent code for former residents/fellows which is lower in the hierarchy than alumni/ae.  On the other hand, the hospital is not a degree granting organization, so the only alumni we have are our former residents and fellows.  The new relationship is different, because the organizations are different.  There is no way for the program to know what the new relationship is unless you record it.

Another example.  In the vast majority of cases, students become alumni once they are no longer students.  However, there are sometimes cases where the students don't complete enough of the curriculum for the organization to consider them alumni.  More importantly, different organizations have different criteria for what is sufficient, e.g., only those actually granted a degree vs. those who completed at least one year.  There is no way for RE to know what your criteria are nor which criteria apply unless you record it.

Or consider your parents who have two students.  Do they become former parents when the first when graduates or only once both students graduate?  Can a person simultaneously be a former parent and a current parent?  If so, which takes precedence?  Again, RE doesn't know unless you record it.

No matter how good RE gets, it will never be able to read your organization's collective mind.  Don't blame the software for not being able to do so.

Drew

I am having a problem with my constituent code end dates -- for example, if I have a volunteer, who stops volunteering, their code would be VOL 1/1/02 -- 1/1/06.  But, when I use filters, such as creating a directory with the filter of consitutent code = VOL, it still pulls in those people whose codes have end dates.  Is there any way to avoid this besides constantly using queries of "code = vol AND end date = blank"?  It seems to render either the filters or end dates useless!

Thank you for the information on this thread; it's very helpful.  You're saying (I think) that when you add an end date to a constituency code, you need to add a new code to explain what their relationship is NOW. We were going to track parents using a "Parent" code with an end date when their child leaves, and leave it at that. But now I'm wondering if we need to add a new code like "former parent" if we ever want to solicit them again (some parents might continue donating after their student graduates). Would it be bad for all former parents to be coded in RE as Parent (Begin date - End date).

 On a related note, our system is configured to automatically add an end date to whatever the constituency code is when the person is marked deceased. Do you think this is necessary?  We still want to view them as an ALUM or whatever. This is useful when pulling lists of deceased for a certain class, such as 50th reunion.

 Thanks for your help.

For your first question - Yes, I think it would be bad. If you just add a parent code with an begindate and end date and they continue to support you - all of their future activity will be categorized as unknown on many canned reports. The Parent code is inactive once the current date on your computer is past the end date on a constituent code so after that date, RE thinks they have no code.

For the second question - typically dead people do not continue to give. Once the end date is added then no future activity is expected for them under that code. Any reporting you do on the giving they gave during the dates when they were an ALUM will still show as ALUM giving because it happened before the end date on that constituent code. Obviously this is different for planned gift donors.We create separate records for estates and put planned gifts on there soft crediting the deceased so this is not an issue for us. If you continue to put their estate gifts on the individual record, you may want to add an ALUM ESTATE constituent code to those people who have a planned gift with you after they die and their ALUM code is inactivated. Then future gifts will be classified in the ALUM ESTATE category.

Thank you.  I think I finally understand how the begin and end dates work!  They tell RE "During this time (begin/end), this person was a _______(parent, student, alum) and here's what they did ___(attended events, made donations,etc.)"  If we code Parents with end dates and don't add another constituency code, RE doesn't "view" them as active constituents.  Your answer on the deceased also makes perfect sense; RE isn't erasing them from the system by adding end dates when marked deceased; the system is correctly indicating that this person will no longer be "participating" in any way, except for the estate issues you mentioned.

Thanks very much~

Susan

Melissa,

 I understand what you are saying about using From/To dates, and I have posed this procedure to my team.  However, they migrated from Benefactor to Raiser's Edge and hired me as the DBA.  The issue they have is that they have to remember to use the date range in their queries.  I have to use the gift constituency for financial reports by constituency code.  The issue I have is they won't track when a Current Parent became a Former Parent and then don't understand when a parent of a recent grad no longer shows up in the solicitaions.  Do you have a policy that I can share with my team to help convince them that it would benefit them?

 

Thanks

Danielle

 

Hi Danielle,

I realize I am coming late to the conversation and that you asked Melissa specifically about the to and from date.

We, like you found using the date range problematic, folks weren't remembering to use those fields in queries. Many of our staff run their own queries so to accommodate the issues we/I created a specific note type that addressed the movement within the constituency codes. We do the changes globally as much as possible and globally add the note before the change is done. For example, when we have current committee members move to former committee members we use a former committee code and the note is committee changes with the Constituency code at the beginning of the description. We use the notes field to list the committee and the term served.

Karen 

I have not created a policy as such for that. And just because someone won't do something does not mean that they should not be doing something. Do you not have the support of your boss, or their boss, in using the system as intended to get the full use of it's capabilities.

You/they do not need to use date ranges in queries if you are simply looking for someone's current constituent code - there is an entire query capability around getting the current primary constituent code (topmost code with a valid date range for the day you run the query).