To add to the confusion we have a constituent code for alumni who work at the University, AE. 

We have always ranked Staff higher than Alumni.  Donors will have a greater impact on giving percentages as a staff member (where there are presumably fewer people) than as an alum.

we rank alumni second only to Board Members:  staff ands faculty just split:

1.Alumni/Board Member 2. Friend/Board Member 3. Alumni 4. Friend (general non alumn individuals) 5. Faculty 6.Staff

Cindy March:

To add to the confusion we have a constituent code for alumni who work at the University, AE. 

What if an employee got their Bachelors somewhere else, and uses their employee benefits to earn their Masters at your school?  Does that change how you interpret the start date?

Do you also code these people separately as Alums and as Employees?  If so, you are duplicating effort; if not, you are losing information.

Drew

 We actually code them as both.  But for us Alums are highest.  We find that as a small private university, keeping Alum at the top allows us to put staff/faculty codes below - most of the requested reports have to do with the types of donors we have - hence why alums are considered most important.  I inherited this system, but after some initial confusion, I think I see why it works.

 We consider alums to be alums forever, so they only have a start date.  The staff/faculty code will have a start and end date (I say will because it's one of those things I'm in the process of cleaning up.)

Drew, tell us how you really feel.  :)

I agree with Drew - unfortunately this is sometimes then a reason for places to say they won't use the date fields at all which I wholehartedly disagree with. 

I agree with Melissa that everything should have dates.

Most of my inherited database has no dates on the constituency codes.  It makes for horrid reporting at times.  Each import of alums I do all have dates - eventually we'll get it worked out.