nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Recording Multiple Ethnicity/Race Values in RENXT

Amelia Ketzle

Hello, all!

My institution is new to RENXT (still in implementation phase) and we are trying to find a home for multiple ethnicities. How is this typically stored? I was surprised not to find this as a discussion topic already. Surely this has come up! How are you all handling it? We have a code in our current alumni database for 'Multi-Ethnic' but this isn't much good for reporting. For example, we have a Black Alumni Group here, and all alumni with an ethnicity code of Black are included in these communications. If someone's code is Multi-Ethnic, however, we miss the fact that one of those ethnicities is Black and they should be included in this particular communication. Has anyone found a good way to store multiple ethnicity/race codes in NXT?

Thank you in advance for any suggestions!

Find more posts tagged with

Comments

roger berg

There are several of those Bio2 fields that don't exist in NXT - including Ethnicity and Religion. I created an attribute for Religion and did several Global adds to update the records. You CAN see attributes (called Custom Fields) in NXT.

Part B of your question - why be generic with a field that you're planning to use specifically? Do you know which races make up each person's multi-ethnicity? A bit clunky, but instead of Multi Ethnic, maybe "Black and X", "Black and X and Y", "Hispanic and X", etc. You could then query/filter based on "contains" rather than "equals" and still pick up all those that you want to invite.

Amelia Ketzle

Thanks, roger berg‍ - we'll give that some thought. Appreciate your suggestions!

Alyson Watts

Constituent Attributes are always good for data that just can't find a home in a native field. I'd be hesitant however to make major changes to my database just to be able to view a data set in webview when it already has a logical home in database view. I understand you might need to do this if it's critical data to even the casual user for daily operations. But considering that enhancements are made to webview every week, and that you can always go back to database view to report on or view data in the meantime, I'd approach major reworkings with caution. (You can check in on quarterly roadmap webinars to find out what enhancements are in the pipeline. And you can suggest ideas in the community to speed certain enhancements along.)

All that being said, you might keep the Multi-Ethnic value in the Ethnicity code table, and add a table-driven Constituent Attribute called "Multi-Ethnic Description". In the table for this new Attribute you could include multiple variations. That way, you could still report (in database view for now!) on the shorter list in the Ethnicity field (especially if this aligns with outside requirements like accreditation reports eg) but still expand upon "multi ethnic" for internal purposes.

roger berg

Great points Alyson -

in my situation I have gift officers that ONLY use NXT and they were wanting to be able to see Religion on constituent records now - not at some unknown point in the future when Blackbaud might make those fields available in NXT. So it's not so much about reporting, it's about giving my NXT only users the ability to see information on their screen that's not yet included. ?

Amelia Ketzle

@roger berg - This is exactly what we ended up doing! When we began this discussion, this solution seemed like it might get out of hand, but as it turns out, we don't have the same reporting needs for each ethnic value. It depends on whether there are ethnically-targeted constituency groups active which are driven by these codes. So we did just create specific multi-ethnic combo values like “Black and Asian”. This has worked so far!

Amelia Ketzle

Thank you, @Alyson Watts ! I agree - I hate to force data into a location just so we can view it in webview if there is a logical, dedicated home for it already in database view. This should be reserved for situations where there's really no other choice. In our case, it was more of a reporting need than a need to see the data in web view, so @roger berg's solution fit the bill! Thanks to you both!