Clarification on Use of Constituency Code vs. Attribute for Board Members in Raiser's Edge

Wanda Hardison · September 3

Raiser’s Edge Database Manager Colleagues and Friends:

I have a question regarding the best practice for entering the "Board Member" designation in Raiser's Edge. My supervisor has asked me to ask this question. Where would you suggest we enter our Board Members' code? Under Constituency Code or as an Attribute.

In my experience, I’ve typically used the Constituency Code to identify board members, as it clearly defines their relationship with the organization. I then use Attributes to capture additional details, such as:

Committees they serve on
Areas of interest
Term dates
Other relevant board-related information

Using Constituency Codes in this way ensures:

Data integrity
Strategic segmentation
Consistent reporting
Effective engagement efforts

This structure also supports core database principles I learned early in my career. Over 30 years ago, my mentor instilled in me the importance of avoiding duplicate code or data structures in the database. Following the DRY (Don't Repeat Yourself) principle and applying normalization helps maintain consistency, reduce maintenance challenges, and ensure long-term system efficiency.

Given this, I’m trying to better understand the rationale behind entering "Board of Trustees" as an Attribute instead.

Under what circumstances would using an Attribute instead of (or in addition to) a Constituency Code be considered best practice?

Would duplicating this information offer any benefits, or could it introduce confusion or inconsistency?

I’d really appreciate your insight into this, especially if there are organizational or reporting needs that justify the use of both or one or the other.

Thank you,

Denise

Laura Neidhold · September 3

Hi Denise,

My organization structures our data exactly like yours. Board membership for both our foundation board and our patent org board is captured in constituent codes, as this is the relationship between donor and org. And the date feature native to constituent codes captures the nature of our ever evolving board.

In attributes, we record committee membership, as well as former committee membership among a slue of other details about the donor including planned giving information, donor interests, dietary preferences, seasonal residency etc. as these fields are easy to query on for this type of information.

Like you, I argue for storing each piece of data only once in the database, so I would work to avoid duplication. I have found that such duplication creates confusion when data is updated in one field but not another.

Dariel Dixon · September 3

What a wonderfully written post @Wanda Hardison. You've distinctly explained exactly how constituent codes should be used and what they are. Textbook. I'm going to stealing a significant amount of that definition as often as possible.

That said…I've got a different perspective. First off, I don't want to bury the lede…I think constituent codes are the best place for them, but I also know that you have to account for management of these codes. Simply, are you going to be placing a date on them (of course you would…but you know that) and how you remember to account for those dates when reporting and querying. Dates in codes can cause considerable consternation…but alas. And will you need to create a "former" constituent code? You see these all the time, but why? The management part of a database manager.

Attributes seem like the path of least resistance, but they are a bigger problem to maintain. Because you have more control over the type of data an attribute/custom field is, that resolves some issues but not all. You still need to have a plan for maintenance.

Allow me to also point out visibility as a reason to use Constituent Code. In DBV and Unified view (sigh), constituent codes are highly visible in ways attributes just aren't. At the bottom of the record in RED or in the constituent header in ahem Unified view.

All these things lead to constituent codes being the best place for most organizations. I think your structure of constituent codes as broad and attributes/custom fields as fine tuning is smart and best practice. I would keep doing what you've been doing.

Allow me to add that I would not duplicate these fields as a constituent code and an attribute under any circumstance. Why double the work and the maintenance? In the words of the great bard of our time Sweet Brown, "Ain't Nobody Got Time For That."

JoAnn Strommen · September 3

Board member is a constituent code for us as well. We have not recorded committee membership in RE at this point but are considering a record for the committee with relationships or attributes. Actually trying to decide if worth the work as RE is not where folks go for that data.

.

Joe Moretti · September 3

Board Member as you do now. That is the best practice.

Devan Bessinger · September 5

Very much agree with you, Wanda! For what it's worth, our practice is that the constituent code is there to tell you "why a constituent is in the database," and we do have this field required. If a person exists in the system because they are a board member, then constituent code is the best place for that data.

(And yes… 😊, I know some people are probably thinking it and hating it, but that does mean we have "Donor" as a constituent code because not all gift records are for actual charitable gifts. Some are for non-charitable purposes, such as item purchases and event registration payments.)

Jennifer Briganti · September 5

I've found it to work well having Boards as a constituent code and also as a volunteer type. You can use the constituent code to reflect the current status, then use the Volunteer type to mark the specific board and start/stop dates. This makes it easy to pull by constituent code but also you have the detail in the Volunteer area.

The problem with attributes is there are no stop dates, so you would have to have an attribute for each year of the committee. Not a big deal, but if you have multiple boards, it does make the entries in the attributes lengthy. I've moved away from tracking committee memberships in attributes.

Shaundra Mitchener · September 5

We are looking to revamp our tracking of 3 boards, 6 committees, and a speakers bureau, so I am intrigued by this thread. All the constituents identified here are Volunteers at their core, and being able to capture dates, tenures, roles, skills, lived experience - all the items that @Wanda Hardison is adding as attributes - in one place would be more useful to me and I think would make the data management much simpler. In my current org, attributes and constituent codes became the wild west, and as was mentioned, suffered from poor maintenance and too much specificity which rendered much of the data close to useless and near impossible to correct.

And this is where I would like to see the Volunteer Module be more robust and flexible. Not every org needs to schedule volunteers for daily shifts but most have board members, fundraising committees, or campaign cabinets. As the volunteer module rollout for webview is still a ways off, I hope that some consideration is being given to improve functionality here.

Meredith Friedman · September 5

We use a Board Member code, but we use NO DATES on our constituency codes - per the recommendation of our RE contact during our onboarding. So we create a new Board Member code each year that lives on their record for perpetuity.

Jaclyn Whitelock · September 5

We use Board member as a constituent code, with the start date when they started serving on the Board, and the date to as the date when they finished their term. (e.g. we do not use "former board member"- instead, if I was querying/reporting on former Board members, I would query on the constituent code and "Date to=not blank").

I definitely agree not to duplicate- and I think @Dariel Dixon makes a really good point about how visible constituent codes are. I would argue that with information as important has "is or has served on the Board", it should be front and centre, not eight tiles down and to the left in webview depending on how the particular user's profile is set up (…Unified View. Sorry, I don't think I'm going to be able to adopt that one!)

Dariel Dixon · September 5

https://community.blackbaud.com/discussion/comment/306530#Comment_306530

I wanted to leave this alone but I couldn't. Why would you do this? What purpose does that serve? Having duplicated codes seems like a nightmare to maintain and query against. Like I stated before, dates cause some problems but none that can't be resolved with proper query structure (@Carlene Johnson I'm looking at you…)

Carlene Johnson · September 5

https://community.blackbaud.com/discussion/comment/306539#Comment_306539

OMG! I'm about to get fired up! @Dariel Dixon, thanks for tagging me in this thread. It is infuriating to me when consultants (either BB or other) give bad advice to clients. @Meredith Friedman, perhaps this works for you and your organization, but I'd argue that it is creating a model where you will end up with dozens of constituent codes which will, in the long run, make querying, reporting, exporting, and lists much more difficult due to the sheer clutter of it. I'd be happy to do a show & tell of how this can be set up much more efficiently.

I'm going to (again) share my two favorite resources from @Bill Connors and should be mandatory reading for anyone thinking about Constituent Codes:

Best Practices in the Use of Constituent Codes (Blackbaud K12 Conference 2019 presentation slides)

“Former” Constituent Codes? (post to fundsvcs)

JR Barden · September 11

Constituent code for quick identification, membership module for more detailed board information such as terms with beginning and end dates, for executive board positions (president, vp, treasurer, etc.) you can use the Program, Category, and Subcategory fields. You can use membership attributes for interest and there is also a notes field.

Using the membership module allows me to report who were board members at any point in time.

Clarification on Use of Constituency Code vs. Attribute for Board Members in Raiser's Edge

Best Answers

Answers

Categories