This would not be possible or even good. Primary constituency code is dynamic intentionally. if you use date fields then the uppermostone for the date range you are reporting on becomes primary even if today they have a different primary. I do not want to have to keep moving checkboxes around - no... no way!

This is a wish list of sorts, correct?
Don't know why you'd have to move checkbox around anymore than you have to move a code to top of list. Why would date fields affect which one is identified as primary any differently?
I'd like to have the option if desired to have a default order for the constituency codes with a check box similar to that used for preferred address for the primary code.

If this became the way to make one primary then I could not put in "future codes" that would kick in as soon as a date passed (graduation date, date they leave the board, etc.) I can not vote for something which I think will cause me to LOSE funcionality I currently have, use and love.

We would at least like the ability to indiciate a hierarchy that would translate to each constituent record, or have the ability to reorder constituent codes when needed without having to export, delete, and import all existing codes. For us, a primary constituent code check box would work. This would differ between individual and organization records.

Joann, Date fields are the PRIMARY way RE identifies which consitutency is primary at any given time. Did you know that if you run a gift detail and summary report on a date range 3 years ago and tell it to summarize on constituency code it uses whatever constituency code would have been primary then - not today. So if, based on date ranges, they were an individual then and are a board member now - their giving PROPERLY goes into the individual line - not board.

The problem with constituency codes is not that there is no checkbox but that people do not use them as designed. As designed they (for the most part) work like a charm.

A default order would never work for us. SOmeone can roll on and off our board so they go from being an individual to a current board member to a former board member to a current board member and all dated so I know during which date range this code applies/applied. If there was a default order what would it do for my person then?

Melissa, that RE has the built-in intelligence to evaluate and use historical primary Constituent Codes is amazing but little understood because it isn't documented well and doesn't work consistently across all aspects of RE. From my experience It only works with certain canned reports. But if you, for instance, want a Constituent Query based on Primary Constituency it should include a Criteria option to let you select the specific date (or date range) so your query can include the "Board Member" list as of that particular date. Guess I need to file this as a Discovery Topic (if it isn't already).

Have not tried it - but why can't you query using both constituent code and date range to get a historical board list? The fields are there - you just would not use "primary constituency" just the plain constituent code.

There is something to be said that the features are little used because of a lack of understanding. It was designed pretty well so maybe BB needs to better document this or better train on it. I don't know the answer, but to make it less functional I would not vote for.

We need a primary constituent code checkbox at least for import purposes. If a record already has constituent code(s), the imports just add the new code to the bottom of the code list. There's not a way to specify that we want to make the imported constituent code be primary. While I agree that reports handle codes pretty well, it's tough to manage the codes when we try to get data imported and/or organized.