Gender is an easy field to fill in at the membership desk and a hard one to change once it’s there. Constituent records in Altru carry a gender value with a short, fixed set of choices. The newer options people now expect, like nonbinary, another identity, or “prefer not to say,” usually aren’t among them. Pronouns, titles, and salutations also tend to assume a binary, so the same gap shows up in your mail merges and acknowledgment letters.
This guide covers what you can change, what you probably can’t, and how to set up your records so you aren’t guessing about anyone.
Start with what the gender field actually allows
In many Altru databases the gender field has been a fixed, system-defined list rather than a code table your administrators can edit. If that’s true in yours, you can’t add a value to it the way you’d add a new title or relationship type. Which values you see, and whether the list is editable, can depend on your version, so don’t rely on what another organization tells you. Check your own.
Before you plan anything, confirm what your own database does:
- Open a test constituent and look at the full list of gender values offered.
- Check your code tables to see whether gender shows up as editable. If it doesn’t, assume it’s fixed.
- If you’re unsure, ask Blackbaud support whether additional gender values are supported in your release, and whether that’s on their roadmap.
If you can’t extend the list, the next step is to change how you use it.
Treat “Unknown” as the honest default
The single most useful change is a policy: staff never infer gender from a name, a voice on the phone, or a household relationship. If the person didn’t tell you, the record says Unknown, or whatever neutral value your list offers.
That sounds small, but it fixes the most common problem. A lot of gender data in a museum or zoo database was guessed by someone at a register years ago. Guessed data is worse than no data. It drives the wrong salutation, it skews any report that segments by gender, and it’s what upsets people when they see it on a letter.
Put the rule in your data entry guide and your seasonal staff training. If you import lists from events or partners, check that the import doesn’t fill gender from a title or a first-name lookup.
Capture identity and pronouns in an attribute
Altru lets you create constituent attributes with your own list of values. That gives you room the built-in field doesn’t. Two attributes cover most needs:
- Gender identity (self-described). A code table with the options your organization chooses, for example woman, man, nonbinary, another identity, and prefer not to say. Only fill it in when the constituent provided it.
- Pronouns. A code table such as she/her, he/him, they/them, and use name only. This is the one that actually affects how staff speak to and write to someone.
A few practical notes:
- Restrict who can edit these attributes if your security setup allows it. Self-reported data should be changed when the person asks, not when a staff member decides.
- Add the attributes to the queries your communications team already uses, so they show up where decisions get made.
- Decide whether you need this data at all for each audience. A donor stewardship team might use pronouns. Your daily admissions process almost certainly doesn’t need either field.
Fix titles, salutations, and household wording
This is where binary assumptions are most visible to the public.
Titles
Titles are typically a code table in Altru. Add Mx. and make sure staff know the record can have no title at all. A blank title is better than a guessed “Mr.” or “Ms.”
Addressees and salutations
Review the name format options your organization uses for letters and email. If your defaults build “Dear Mr. and Mrs. Lastname,” add formats that use first and last names, like “Dear Jordan and Sam,” and make those the default for new records. Run a query on your existing records to see how many use title-based salutations, then decide whether to update them in bulk or as people renew.
Relationships
Household and relationship types often include husband and wife pairs. Check your relationship type code table for neutral options such as spouse or partner, and add them if they’re missing. Use them as the default when someone doesn’t specify.
Change what your forms ask
Every field you collect is a field you have to maintain. Look at your membership, donation, and ticketing forms, online and on paper, and ask why each one collects gender.
- If no report or program uses it, remove the question.
- If you do need it, make it optional, offer a “prefer not to say” choice, and map answers to your self-described attribute rather than forcing them into the fixed field.
- Ask for pronouns separately, and explain why you’re asking (“so we address you correctly in member communications”).
Whether your web forms can write to a custom attribute depends on how they’re built. Test in a sandbox or a low-traffic form before you rely on it.
Clean up the data you already have
Once the new setup is in place, deal with the history:
- Build a query of constituents who have a gender value but nothing in the new self-described attribute. Altru generally won’t tell you who entered a value or why, so treat that whole group as possibly guessed.
- Decide on a policy: reset those values to Unknown, or leave them and stop relying on them for salutations.
- Check any reports, smart fields, or segments that filter on gender. Update them to use the new attributes, or retire them.
- Write down what you changed and when, so whoever runs reports next year understands why the numbers shifted.
Quick answers
Can I add “nonbinary” directly to the gender field in Altru?
In most databases, no, because the list is system-defined. Confirm in your own version, and use a custom attribute if you can’t.
Should we store sex and gender separately?
Only if a specific program needs it, which is rare for a cultural organization. Most teams are better off collecting less and focusing on pronouns and correct salutations.
