finalizing constituent codes w/ few questions

After some trial and error, my preference for Donor Listing is as an Attribute.  This way, it doesn't get accidentally changed if someone adds or changes text in the fields composing the addressee/salutation.  Our default Listing is the same as Home Formal (i.e. Dr. & Mrs. Robert C. Hernandez) so I typically check the Edit box on that Addressee, copy the text, uncheck the box, and go paste the text in the Attribute.  (Once it became habit, it doesn't take nearly as long as it sounds.  And the initial setup I did with Export/Import processes, which I occasionally do again with a large number of new records.)  Keeping the Listing Text on an Attribute means this location is also available for Org Records, which don't have an Addr/Sal Tab.


However, most of this is your choice as an organization.  You need to set things up in a way that makes the most sense for you and for how you will be using the data.  I strongly recommend setting up and keeping several dummy records to test different things with, where you don't have to worry about restoring or messing up real records.  I have 4, an organization and then a couple each with their own record and a couple on one single record.  They have a Dummy Record Constituent Code that lets me exclude them from any real processes (queries, reports, etc) I may be doing.


As to your legacy group.  We do track this as a Constituent Code.  Two, actually.  One for the Legacy Society, meaning they've already made us aware of a bequest or other intention, and one for Legacy Prospect, meaning we've either started conversations, know of some interest, or want to approach the topic with that person.


In general, I use Constituent Codes for how the constituent is connected to my org, usually in a way that doesn't often change, and that can't very easily be pulled in some other way.  So I don't use a Const Code of "donor" because I can determine that from data on the Gift Tab (and this category could, in theory, change frequently...or more likely, the parameters for what types of donors we're pulling will change and this Const Code wouldn't be helpful).  Information that I want to have visible on Bio 1 (Const Codes appear at the bottom in red text) will go in as Const Codes.  Also information that I may want to use to quickly group records...often, that data is duplicated elsewhere.  For example, board members have a Constituent Code (set to Primary Constituency when an active board member), but the full details of their board service is on the Volunteer Tab.  I could pull a simple list of board members from either Const Code or Volunteer Tab, but it's generally faster from Const Code.  (And I want the Board Member status and associated dates to appear on Bio 1 for others to see.)


For Tribute Records, I assume you mean records you are adding for a person already deceased.  In the past, at my current org, they prefixed the Const ID with "Trib" to identify records added for the sole reason of storing data for a tribute when the new record is already deceased.  You could use a Constituent Code for this, which might make more sense...again, it depends on your org and how many of this situation you will find.  I would prefer a Const Code over a Const ID prefix.


When a constituent passes and leaves a gift for us in the estate, it depends.  If it's a one- (or maybe two-) time payout, I will change the Primary Const Code on the Ind record, and also update the Donor Listing in the Attribute.  If we expect to receive on-going payments or there is a surviving spouse (or some other reason to keep the Ind record as-is), then I will create a new record for the estate.  (And link them with a Relationship Record.)


For your auxillary situation, if you have the Volunteer Tab, this might work for you.  Otherwise, I suspect Relationship Records, as you mentioned, may be your best bet.


Ultimately, you'll need to think thru what will work best for how you need to be able to use/access/pull this data down the road.  In general, I try not to duplicate data unless it's necessary or helpful, and certainly only when there is low/no risk of that duplication causing issues (i.e. Solicit Codes...for that, there should be only one system).  A good Policies & Procedures Manual, or at least a collection of documentation, is a smart idea, because it will explain to others why your data is stored as it is...and how to use it if you're not available (when I worked in theater, we called that the "hit by a bus contingency plan").