Retaining former names for transgender alumni?
My personal opinion is that we don't need to keep the old information in RE, since there will still be a record of it in the student database should we ever need it for some reason. I may not be totally objective on this one though, as I'm transgender myself and also an alumnus of the institution I work for, therefore one of the affected records is mine! ?
Eager to hear what everyone else's processes are!
Comments
-
I record any former names as alias.
We want to be able to find record if looking for a specific alum without having to contact registrar's office and wait on a reply. Or if someone says we're missing a record, we can quickly determine individual is in db just with change to name.5 -
I would keep it somewhere in your database. If it's not in the alias, then perhaps a note or an attribute? So that it's findable somewhere if need be. I've had the weirdest situations come up where I needed to know a former name of a person or a business and it's been the saving grace!
It's not often that we find ourselves part of the situation we're asking about, is it?3 -
We keep the information in a note along with any corresponding letter or email we received from that individual.
As the mother of a transgender person I don't believe that it would be respectful to save it as an alias. This person has truly changed their name. Their former name is not an alias. This person is now known by their new name and by their class year. Thinking that we would readily need their previous name is a little intrusive.7 -
We use Alias for more than an "alias." We also store employee ID numbers there, dba names for orgs or individuals, legal name, incorrect name and more. I would respect what the donor wants us to use for their name but we keep the name history in there to help others who look at the record. I see it as an "internal use only" part of RE.7
-
Former name is the type we use. "Alias" is just RE's name for field/storage place.
Isn't it similar to someone who changes their name legally by marriage/divorce/remarriage. None are names currently used. We maintain those names so if someone, another alum/faculty, is looking for the person by the former name that they know we can hopefully find their record. Definitely not needed often or used in contacting or lists.
I'm not in your shoes so I don't have your perspective. Thanks for sharing.3 -
Our org was just discussing this same topic last week.
We were going with the idea of keeping the dead name as the first name and putting their current name in Nickname/Preferred Name. Joanne's idea is better if you don't want the dead name immediately visible anywhere on the record and so it's clear the name is a deadname vs a Nickname.
Even if your student system has this info I agree with others keeping it in the fundraising system also for convenience.
I know this is flirting with bad practice but I'd be hesitant to store Gender in any other field (strongly anti-attribute as much as possible). I'd rather add two values to the existing Gender code table: Non-Binary(or [Gender] Fluid)/Female and Non-Binary(or [Gender] Fluid)/Male, with the policy being that the binary gender at the end is the former one. For transitions from one binary to the other, the Gender value will present their post-transition classification. The presence of the deadname on the record would indicate they used to classify under the opposite gender.3 -
I would think it would be important to keep the former name somewhere searchable, so you can identify that record as belonging to the same person, whichever name you happen to have available for searching in the future. I don't think I'd bother trying to retain their former gender code, though. Maybe just a note describing the source of the information so future entry operators will know the change was deliberate and confirmed rather than a mistake/entry error.3
-
I see that I missed a piece of your post when I made my first reply, my apologies.
I second the thought of keeping the gender field to whatever option is correct for "now," and the only reason I'd bother with making a note anywhere would be only to indicate that it's a purposeful change, as Amelia Ketzle suggests. Another piece that goes along with this field is the title field. You may want to have a data quality query, that is reviewed regularly, for a while after you implement this that analyzes your gender field against your title field for mis-matches.
If your org is familiar with the term "dead name," then I'd suggest using that as the alias type. If not, "former name" may be better, at least to start with.3 -
Karintha Marshall:
Our org was just discussing this same topic last week.
We were going with the idea of keeping the dead name as the first name and putting their current name in Nickname/Preferred Name. Joanne's idea is better if you don't want the dead name immediately visible anywhere on the record and so it's clear the name is a deadname vs a Nickname.
Even if your student system has this info I agree with others keeping it in the fundraising system also for convenience.
I know this is flirting with bad practice but I'd be hesitant to store Gender in any other field (strongly anti-attribute as much as possible). I'd rather add two values to the existing Gender code table: Non-Binary(or [Gender] Fluid)/Female and Non-Binary(or [Gender] Fluid)/Male, with the policy being that the binary gender at the end is the former one. For transitions from one binary to the other, the Gender value will present their post-transition classification. The presence of the deadname on the record would indicate they used to classify under the opposite gender.There is absolutely no reason to add /Female or /Male to the gender table or any "previous gender" anywhere on the record unless you are a medical practice (in which case, you should not be using a Blackbaud product to store medical information). Please do not do this.
As for storing a former name, I would put it in the alias field with a type of "former name." That way it can be found, but it is clearly noted that the name is no longer used.8 -
I registered alarm in this response, that prompted me to do some digging.
After a bit of reading I can see how storing medical information in the fundraising system flirts with disclosure of personal health health info, thanks for framing this as medical info vs. general metadata. Hadn't looked at gender that way but it certainly is.
Attached is a PDF on the use personal healthcare info in fundraising communications, which also lists HIPAA provisions. Seems like a good reference resource.
7 -
Thank you all for your input - I had a feeling that there would be as many different ways of tackling this as there are organisations using RE! ?
We're definitely not going to retain a record of the previous gender value, I'm not sure about the name - it feels different to keeping someone's maiden name on file as it would instantly "out" someone as being transgender whereas being married has no stigma attached, so it's more sensitive data than simply a name. I have some food for thought anyway!4 -
Heather MacKenzie:
If your org is familiar with the term "dead name," then I'd suggest using that as the alias type. If not, "former name" may be better, at least to start with.Thanks Heather - I'm familiar with the term, I can't vouch for the rest of my team. We do already have a "former name" alias that we use for divorced people etc. so that's an option. I'm not sure I'd want to add a new alias type just for trans constituents, since that creates the potential for someone to run a query that essentially says "give me a list of all the trans people in the database". I'm sure nobody would do that, but you never know.
3 -
absolutely keep it. It's part of their history and if you are an educational institution, you will not be able to find their official or unofficial (transcripts, yearbooks, scrapbooks, photos) if you do not have their former name as a reference.
I have had do address this a couple times, but not many. I wrote a note with the dialogue explaining the change and from what to what and when, including name and gender and if they also gave pronouns and title preferences..
And have put the former name in the Alias field also. The title would also change on Bio 1accordingly (if you are an org that uses them).5 -
We update the name to the transitioned name and retain the former name, legal name, dead name as an alias. The justification for for retaining the name as an alias is searchability from web view. From web view the status of the name is available on the constituent summary tile. We capture pronouns as an attribute in db view and include them as a summary note in web view. As a summary note the pronouns are front and center. The redundancy is for the fundraisers. Pronouns stored as an attribute are at risk of being overlooked while scrolling through tiles. I also did not want the pronouns to be unique to web view and have the potential to be lost in the event of catastrophic reset.3
-
Alan French:
Heather MacKenzie:
If your org is familiar with the term "dead name," then I'd suggest using that as the alias type. If not, "former name" may be better, at least to start with.Thanks Heather - I'm familiar with the term, I can't vouch for the rest of my team. We do already have a "former name" alias that we use for divorced people etc. so that's an option. I'm not sure I'd want to add a new alias type just for trans constituents, since that creates the potential for someone to run a query that essentially says "give me a list of all the trans people in the database". I'm sure nobody would do that, but you never know.
Good point there, Alan French, I hadn't thought of that becoming a possibility. I agree with your thinking!
1 -
Alan French:
Thank you all for your input - I had a feeling that there would be as many different ways of tackling this as there are organisations using RE! ?
We're definitely not going to retain a record of the previous gender value, I'm not sure about the name - it feels different to keeping someone's maiden name on file as it would instantly "out" someone as being transgender whereas being married has no stigma attached, so it's more sensitive data than simply a name. I have some food for thought anyway!A thought about the Former Name Alias - In a former database of mine, we used "former name" for situations besides getting married and we used the "maiden name" field for recording the pre-marriage last name. People and businesses both do change their names without it being related to anything beyond wanting to change their name. So, it was already set up for us to use it for any reason someone changed their name, first, last or anything in the middle. Someone I went to school with was Molly, then changed her name to Faxon. It can be a bigger thing when getting married than just the last name - I changed both my middle and my last name when I got married. We had a church that changed it's name as well, plus a couple businesses. So, in my world here in California, that alias could mean one of a large variety of situations, including the one you're talking about.
What you feel is what you feel. I respect that. This is just my 2 cents. :- )4 -
This is quite the conversation. I find myself vacillating about it the more I think about it. The constituent has informed us of their wishes and we should act accordingly. Understanding the pain that a dead name can bring, I would want to tread very lightly and think that it would be wise to overwrite the old information with the new.
However, if it was not a transition of gender, and just a change brought about by a marriage or divorce, I would absolutely keep the former name. But, I also don't think the two situations are the same by any stretch of the imagination. The biggest issue is that if you decide to keep that data, how do you keep it and have it searchable without using it as an alias? I don't know. Obviously, the only time someone would search for the dead name is if they were not aware, so you would have to have it where it would be searched by name.4 -
Dariel Dixon:
Obviously, the only time someone would search for the dead name is if they were not aware, so you would have to have it where it would be searched by name.And this is where I think Alias is not so useful for changes of first name - the Alias field only works in conjunction with the surname field for searches. If an alias was "Jane Doe" and someone searches for "Jane" in the first name field and "Doe" in the surname field, that record wouldn't be included in the results. There isn't really a better place to keep it though!
4 -
Alan French:
And this is where I think Alias is not so useful for changes of first name - the Alias field only works in conjunction with the surname field for searches. If an alias was "Jane Doe" and someone searches for "Jane" in the first name field and "Doe" in the surname field, that record wouldn't be included in the results. There isn't really a better place to keep it though!
Perhaps this might be a helpful addition to this thread:
I set up RE to store all our name related aliases (id, phonetic spellings, org recognition names are the other types of aliases I store) as last, first and the technical fundraisers are taught that if they are having difficulty finding someone they are to search by last, first (spelled out) in the last name field and that has been helpful. The alias type field (Ind-Birth Name (last, first), Ind-Legal Name (last, first), Ind-Previous Nickname (last, nick), etc.) is clear with that expectation. As you can see I set up the aliases that pertain to individuals as Ind-. My commonly used org aliases start with Org- and ids start with ID-7 -
Thanks Elizabeth Johnson, that sounds like a very efficient system!3
-
Elizabeth Johnson:
Alan French:
And this is where I think Alias is not so useful for changes of first name - the Alias field only works in conjunction with the surname field for searches. If an alias was "Jane Doe" and someone searches for "Jane" in the first name field and "Doe" in the surname field, that record wouldn't be included in the results. There isn't really a better place to keep it though!
Perhaps this might be a helpful addition to this thread:
I set up RE to store all our name related aliases (id, phonetic spellings, org recognition names are the other types of aliases I store) as last, first and the technical fundraisers are taught that if they are having difficulty finding someone they are to search by last, first (spelled out) in the last name field and that has been helpful. The alias type field (Ind-Birth Name (last, first), Ind-Legal Name (last, first), Ind-Previous Nickname (last, nick), etc.) is clear with that expectation. As you can see I set up the aliases that pertain to individuals as Ind-. My commonly used org aliases start with Org- and ids start with ID-Creative use! It sounds like you've come up with some great ways to work with the limitations of RE. This illustrates perfectly how user-UNfriendly the search capabilities in Alias are in RE. The search capabilities need to be nimble and smart, not rely on training and very specific usage by data entry operators and others searching for records. There is too much room for error having to rely on such methods. BB really needs to improve the way this part of the database works!
5 -
Thank you for asking this question. It's been very thought provoking. We use former name in alias and I change the gender to that which honors the person. I see no need to keep historic gender information. Since we do often refer to our yearbooks for additional alumni information, it has been helpful to keep the alias. I'm glad you mentioned the importance of not labeling it dead name. I'd like to think everyone honors the person, but you're correct that it opens the possibility of singling out - it's sad to consider this in the world of social good, but it can be a reality. So glad you shared!4
-
I'd second all the recommendations to keep it under Alias as a “former name” with the Last, First name format for searchability. Many people change their names, from all walks: I know people personally that have gone through legal name change for religious, family, adoptive, and other circumstances. Our monks even change their first name upon taking final vows, although it's not a legal change. I would never think of addressing our monk by his birth (first) name.
Regardless of any religious/political views, it's not our business to ask why a person changes their desired name. It is our business to be able to conduct effective data appends and maintain accurate alumni records. So, retaining past name info while standardizing the alias type to “former name” accomplishes that while respecting donor privacy.
2 -
The way I saw it dealt with - inherited - and I agreed with the thought process and continued moving forward - was to keep the old name and gender in the constituent notes as a history item, and in alias.
Yes, you are correct that the student database would have the info, you hope. And I know that a transgender person considers the old as non-existent at that point. But for example, what if another alum is looking for “Sally” and you cannot find them because they have been deleted. You need some way of finding “Sally” so that you can then contact “Joe”, formerly “Sally” and let them know a former classmate is looking for them.
You have to keep in mind, it's not just about whoever is keeping the data now/currently, it's about what you are leaving for others that will tell the story of each alum, whether that be the clubs they were on, the teams they played on, marriage, children, careers and yes, gender changes.
Just my POV.
3
Categories
- All Categories
- Shannon parent
- shannon 2
- shannon 1
- 21 Advocacy DC Users Group
- 14 BBCRM PAG Discussions
- 89 High Education Program Advisory Group (HE PAG)
- 28 Luminate CRM DC Users Group
- 8 DC Luminate CRM Users Group
- Luminate PAG
- 5.9K Blackbaud Altru®
- 58 Blackbaud Award Management™ and Blackbaud Stewardship Management™
- 409 bbcon®
- 2K Blackbaud CRM™ and Blackbaud Internet Solutions™
- donorCentrics®
- 1.1K Blackbaud eTapestry®
- 2.8K Blackbaud Financial Edge NXT®
- 1.1K Blackbaud Grantmaking™
- 527 Education Management Solutions for Higher Education
- 21 Blackbaud Impact Edge™
- 1 JustGiving® from Blackbaud®
- 4.6K Education Management Solutions for K-12 Schools
- Blackbaud Luminate Online & Blackbaud TeamRaiser
- 16.4K Blackbaud Raiser's Edge NXT®
- 4.1K SKY Developer
- 547 ResearchPoint™
- 151 Blackbaud Tuition Management™
- 1 YourCause® from Blackbaud®
- 61 everydayhero
- 3 Campaign Ideas
- 58 General Discussion
- 115 Blackbaud ID
- 87 K-12 Blackbaud ID
- 6 Admin Console
- 949 Organizational Best Practices
- 353 The Tap (Just for Fun)
- 235 Blackbaud Community Feedback Forum
- 124 Ninja Secret Society
- 32 Blackbaud Raiser's Edge NXT® Receipting EAP
- 55 Admissions Event Management EAP
- 18 MobilePay Terminal + BBID Canada EAP
- 36 EAP for New Email Campaigns Experience in Blackbaud Luminate Online®
- 109 EAP for 360 Student Profile in Blackbaud Student Information System
- 41 EAP for Assessment Builder in Blackbaud Learning Management System™
- 9 Technical Preview for SKY API for Blackbaud CRM™ and Blackbaud Altru®
- 55 Community Advisory Group
- 46 Blackbaud Community Ideas
- 26 Blackbaud Community Challenges
- 7 Security Testing Forum
- 1.1K ARCHIVED FORUMS | Inactive and/or Completed EAPs
- 3 Blackbaud Staff Discussions
- 7.7K ARCHIVED FORUM CATEGORY [ID 304]
- 1 Blackbaud Partners Discussions
- 1 Blackbaud Giving Search™
- 35 EAP Student Assignment Details and Assignment Center
- 39 EAP Core - Roles and Tasks
- 59 Blackbaud Community All-Stars Discussions
- 20 Blackbaud Raiser's Edge NXT® Online Giving EAP
- Diocesan Blackbaud Raiser’s Edge NXT® User’s Group
- 2 Blackbaud Consultant’s Community
- 43 End of Term Grade Entry EAP
- 92 EAP for Query in Blackbaud Raiser's Edge NXT®
- 38 Standard Reports for Blackbaud Raiser's Edge NXT® EAP
- 12 Payments Assistant for Blackbaud Financial Edge NXT® EAP
- 6 Ask an All Star (Austen Brown)
- 8 Ask an All-Star Alex Wong (Blackbaud Raiser's Edge NXT®)
- 1 Ask an All-Star Alex Wong (Blackbaud Financial Edge NXT®)
- 6 Ask an All-Star (Christine Robertson)
- 21 Ask an Expert (Anthony Gallo)
- Blackbaud Francophone Group
- 22 Ask an Expert (David Springer)
- 4 Raiser's Edge NXT PowerUp Challenge #1 (Query)
- 6 Ask an All-Star Sunshine Reinken Watson and Carlene Johnson
- 4 Raiser's Edge NXT PowerUp Challenge: Events
- 14 Ask an All-Star (Elizabeth Johnson)
- 7 Ask an Expert (Stephen Churchill)
- 2025 ARCHIVED FORUM POSTS
- 322 ARCHIVED | Financial Edge® Tips and Tricks
- 164 ARCHIVED | Raiser's Edge® Blog
- 300 ARCHIVED | Raiser's Edge® Blog
- 441 ARCHIVED | Blackbaud Altru® Tips and Tricks
- 66 ARCHIVED | Blackbaud NetCommunity™ Blog
- 211 ARCHIVED | Blackbaud Target Analytics® Tips and Tricks
- 47 Blackbaud CRM Higher Ed Product Advisory Group (HE PAG)
- Luminate CRM DC Users Group
- 225 ARCHIVED | Blackbaud eTapestry® Tips and Tricks
- 1 Blackbaud eTapestry® Know How Blog
- 19 Blackbaud CRM Product Advisory Group (BBCRM PAG)
- 1 Blackbaud K-12 Education Solutions™ Blog
- 280 ARCHIVED | Mixed Community Announcements
- 3 ARCHIVED | Blackbaud Corporations™ & Blackbaud Foundations™ Hosting Status
- 1 npEngage
- 24 ARCHIVED | K-12 Announcements
- 15 ARCHIVED | FIMS Host*Net Hosting Status
- 23 ARCHIVED | Blackbaud Outcomes & Online Applications (IGAM) Hosting Status
- 22 ARCHIVED | Blackbaud DonorCentral Hosting Status
- 14 ARCHIVED | Blackbaud Grantmaking™ UK Hosting Status
- 117 ARCHIVED | Blackbaud CRM™ and Blackbaud Internet Solutions™ Announcements
- 50 Blackbaud NetCommunity™ Blog
- 169 ARCHIVED | Blackbaud Grantmaking™ Tips and Tricks
- Advocacy DC Users Group
- 718 Community News
- Blackbaud Altru® Hosting Status
- 104 ARCHIVED | Member Spotlight
- 145 ARCHIVED | Hosting Blog
- 149 JustGiving® from Blackbaud® Blog
- 97 ARCHIVED | bbcon® Blogs
- 19 ARCHIVED | Blackbaud Luminate CRM™ Announcements
- 161 Luminate Advocacy News
- 187 Organizational Best Practices Blog
- 67 everydayhero Blog
- 52 Blackbaud SKY® Reporting Announcements
- 17 ARCHIVED | Blackbaud SKY® Reporting for K-12 Announcements
- 3 Luminate Online Product Advisory Group (LO PAG)
- 81 ARCHIVED | JustGiving® from Blackbaud® Tips and Tricks
- 1 ARCHIVED | K-12 Conference Blog
- Blackbaud Church Management™ Announcements
- ARCHIVED | Blackbaud Award Management™ and Blackbaud Stewardship Management™ Announcements
- 1 Blackbaud Peer-to-Peer Fundraising™, Powered by JustGiving® Blogs
- 39 Tips, Tricks, and Timesavers!
- 56 Blackbaud Church Management™ Resources
- 154 Blackbaud Church Management™ Announcements
- 1 ARCHIVED | Blackbaud Church Management™ Tips and Tricks
- 11 ARCHIVED | Blackbaud Higher Education Solutions™ Announcements
- 7 ARCHIVED | Blackbaud Guided Fundraising™ Blog
- 2 Blackbaud Fundraiser Performance Management™ Blog
- 9 Foundations Events and Content
- 14 ARCHIVED | Blog Posts
- 2 ARCHIVED | Blackbaud FIMS™ Announcement and Tips
- 59 Blackbaud Partner Announcements
- 10 ARCHIVED | Blackbaud Impact Edge™ EAP Blogs
- 1 Community Help Blogs
- Diocesan Blackbaud Raiser’s Edge NXT® Users' Group
- Blackbaud Consultant’s Community
- Blackbaud Francophone Group
- 1 BLOG ARCHIVE CATEGORY
- Blackbaud Community™ Discussions
- 8.3K Blackbaud Luminate Online® & Blackbaud TeamRaiser® Discussions
- 5.7K Jobs Board