Constituent codes alternative in Raiser's Edge

Nancy Andujar

Hi, I am working on Const. Codes cleanup and I am looking for other alternative placements in RE database view.

Does anyone have any alternative suggestions for managing Const. Codes?

Does anyone else track Const. Codes i.e. in Attributes, Events, Prospect or Membership Module?

How do I handle if a constituent is part of several groups?

Would attribute make reporting easier? Can this info be easily viewed in NXT and/or pulled in Export without needing to add too many additional columns?

Thanks,

Nancy

JoAnn Strommen

@Nancy Andujar Welcome to the BB Community

Why are you looking for an alternative? What is the issue with using C Code field?

The constituent code structure generally works well. You determine a reasonable list of codes for ‘why is this record in our database’ and determine a hierarchy. CCodes are easy to filter in query, export and most reports. Records can have multiple codes. IMO, the only thing that gets a little messy is the ‘date to’ data.

Have you looked at record in NXT? The constituent code is at top left - right in view. If you were to move it to attributes it would require more work to view.

There are some pieces of data in RE that can be stored in a variety of places but I would use designated field for C Codes every time.

Nancy Andujar

@JoAnn Strommen
As to why - we need to narrow down the number of Const. Codes in a donors records. This can also be tracked in attributes but was looking for other alternatives.

I agree with all your comments and appreciate all your feedback, this is just a preference that my manager has requested.

You mentioned that there are some pieces of data in RE that can be stored in a variety of places, can you tell me where?

Also, can you explain what do you mean by use designated field for C Codes every time?

JoAnn Strommen

@Nancy Andujar By designated field every time - I just mean to use that field for C Codes - not putting what are truly constituent codes elsewhere.

Places data can be stored:
Repurposed fields that are not in use on bio 2 tab

Notes - can be used for lots of things but difficult to search

Relationships - is code about relationship? You can use a record for something like Board or committee membership with relationships to the members

Other modules like prospect, volunteer, events or membership if you have them and a good fit

Attributes - If I were looking at having to move data from C Codes I think I'd go here. Set a category like ‘secondary constituent code’ or appropriate name and then use a table in the description field. That consistent spelling would be key to filtering using anything stored somewhere.

In webview, look at a record in your system that has a good amount of data. Attributes/Custom fields are sorted in alpha/reverse alpha order. How important is the code info? We have records with over 25 attributes so it can take some viewing of various pages to get to the right attribute. That is the one drawback I see about putting things in attributes - viewing in webview.

Karen Diener

My apologies but my inquisitive nature just needs to ask why you need to narrow them down. Did someone say there are too many? Are they somewhat redundant and could be consolidated?

I have definitely worked on projects to move some constituent codes to attributes, and to remove others completely. But it is after a lot of discussion about the codes themselves first and if the information it presents for you is useful. If it is important, but maybe doesn't need to be a ConsCode, then yes, I would consider moving it.

I've removed codes such as Sustainer Donors, Donors, Major Donor, and Prospect. These codes are fluid, and every time I've audited a database with these codes, there are constituents whose giving does not align with their assigned constituent code.

What have I moved? Typically committee assignments for the board or for volunteers. If the client uses the volunteer module I have usually moved them there. Otherwise they have moved to Attributes.

Hopefully that is helpful. What JoAnn said is 100% true. The structure works well, and the code should explain why someone is in your database. I would add that it generally should be unique information - something you cannot learn from other data, such as “Donor”. If someone has gifts, it shows they are a donor and you don't need to add a cons code. It also should be something that does not change a lot, or else you'll get caught up in ongoing data updates.

Good luck working through this!! It isn't always easy, but it is important!

Karen

Sherry Aldrich

@Nancy Andujar We use our const codes for the bigger umbrella of how the person interacts with our school Then we have a heirarchy of what should be the primary. Say a parent is also a board member. Board Member is the primary.

We also use attributes to give us more information about the bigger category. For examples; Say a parent is a parent of a current student, parent of a graduated student and parent of our hs program, parent of former student etc. We are pretty clear on our naming convention. This lets us look at the bigger group of “Parent” as a const code, but also lets us pull specific parents out for marketing / stewardship / communications.

Thanks

Sherry