Gender and pronouns

To view and update the settings for gender values and default pronouns, platform managers should select Core, Users, User profile settings, Gender. For additional instructions, see Table values for gender.

To configure options for preferred pronouns, select Pronouns from User profile settings. For additional instructions, see Table values for pronouns.

In Core, Security, Profile access, a platform manager determines whether to enable users to View and Edit their gender and preferred pronouns. Refer to profile fields for instructions.

A user can only see the gender value and preferred pronouns of another individual if

• the user has a role or task that enables the user to manage contact card data,

• or the gender value and preferred pronoun is published to the individual's contact card and the individual's contact card is also accessible from a Directory or Roster.

In Core, Security, Profile access, a platform manager determines whether users with specific roles can choose to publish or hide their pronouns from other users based on their roles. For example, students may want their peers and teachers to know their pronouns, but may want the option to hide this information from some non-teaching staff and incoming students (who they haven’t met yet).

Platform managers, contact card managers, and users with access to edit their Contact card, can use General information to manage basic biographical information, including gender.

When you enter contact card data for a user, the default pronouns for the selected gender appear, but you can select different preferred pronouns.

• To edit your own information, select your name from the account menu (top corner) and select Profile. Select Contact card. Under General information, select Edit. Enter your changes and then select Save.

• To edit information on another user's behalf, in Core use the People finder to access a user's profile. Select Contact card. Under General information, select Edit. Enter your changes and then select Save.

• Preferred pronouns for each gender may be provided by default. If so, you can select to enter custom pronouns for specific individuals.

If a user edits this information or if someone with access edits the information on the user's behalf, the information will appear for review when your school handles profile changes. If this change was unexpected, you can contact the user to confirm whether the change was intentional. If the change was a data entry error, you can correct it. If the change was intentional, you can discuss communication and accommodation preferences.

Most employees who are responsible for keeping user profile data updated should have the contact card manager role instead of platform manager role (and its clones).

Learn how to manage roles and tasks for users.

Contact card managers can handle personal data common to any user (including contact information, demographics, relationships, emergency contacts, business, and education information).

• From Core, you can use the People finder to go to a user's profile and Contact card to make changes.

• From Core, Users, you can also select Handle profile changes to review the changes users have made or that other administrators made on a user’s behalf.

We recommend schools also use the contact card manager role to grant API access to any of our third party partners who rely on accessing or updating Contact card data. It ensures that the API access is limited strictly to the data they need.

We recommend schools grant the platform manager role sparingly.

Schools should avoid granting users a clone of the platform manager role, even when they remove unwanted tasks to limit the clone's access (as much as possible) to only contact card functionality. If your school relies on clones, consider replacing them with the contact card manager role instead.

When platform managers receive new tasks or an existing task it updated, schools with clones must review the clones to ensure their access is still appropriated limited (not too little nor too much power).

Although some schools do not consider the gender of students to be an important factor for enrollment, other schools do.

• Schools may prefer to limit enrollment based on gender.

• Schools may prefer to intentionally balance enrollment to ensure approximately even numbers of male and female students.

• Schools may prefer to avoid collecting gender data during admissions for "gender blind" enrollments.

Your school will probably learn the gender of many individuals during the admissions process from inquiry forms, application forms , events, visits, interviews, and more.

When you create inquiry forms or application forms review the blocks and locate the gender fields. Determine whether to Show the field on the form and whether the field should be Required. If the field is included, select Dropdown (options). By default, options are enabled for individuals to indicate gender as male (M), female (F), or other (O).

To remove a gender value from the Dropdown (Options) available on an admissions form, clear the checkbox to deselect it. Individuals whose gender is not listed might contact your school by phone or email to inquire about your policies and processes. Alternatively, they might select a gender that is listed and expect to discuss any relevant policies during the admissions process. Some might exit the form and focus attention towards a different school, instead of continuing the admissions process with your school.

Schools who use SKY Reporting or NXT products may be more likely to notice that Blackbaud now uses the terms "alum" and "alums" for all new features and updates to existing features. You may notice a shift to "alum" and "alums" in other aspects of our written documentation for schools too.

These terms are

• more casual,

• more modern,

• more concise,

• more gender neutral,

• and reduce grammatical errors

compared to the terms we previously used.

Previously, we used the traditional Latin terms of "alumnus" (masculine, singular) and "alumni" (masculine, plural) by default, even when groups were co-ed. We did not typically use the traditional (Latin) feminine forms, "alumna" (singular) and "alumnae" (plural) even when a group of individuals were all female.

Sports teams may be designated as designed for male, female, or co-ed.

Platform managers and coaches can add users of any gender to a team roster, regardless of whether the team is officially designated as male, female or co-ed.

Although some schools do not consider the gender of students during course scheduling, other schools may consider gender an important factor. For example, schools may prefer to:

• teach sections of certain classes (such as health) separately based on gender.

• intentionally balance classes to ensure sections have approximately even numbers of male and female students.

To do this, open the Course record, select Course requests, and then select which gender Scheduling should take into account when the schedule manager runs Generate student schedules.

If a gender is specified for a course, then students whose gender is "unknown/blank", "other (O)," or does not match the selected gender, will be excluded from the course. However, you can manually adjust schedules for specific students (such as those whose gender was not known) to place them in appropriate courses.

Refer to Course Requests to learn more about setting up course requests.

Platform managers can create an unlimited number of "Admin View" custom fields (which can be different data types) and up to 10 custom text fields (which are publishable). To learn more, refer to custom user fields.

When dorm group managers setup buildings and rooms (including for dorms and other residence life usage), you determine the names and categories for each building. You determine the number of rooms in each building. You also determine the number, name, code, and capacity for each room.

Many of these settings are text fields which enable you to enter both numbers and letters. This makes gives you considerable flexibility to use these fields however your school needs.

If gender is an important factor for dorm and residence life at your school, you can use these fields to indicate whether certain places are for gender specific or co-ed use. For example, you might create a building named "Helios Residence Hall" and indicate that the building is for both "Dorms" and "Activities." Within the building, you might have rooms such as:

• Number "000," Name "Terra Dining Hall," Code "General," Capacity "75"

• Number "010," Name "Blue Ridge," Code "Suite - Dorm Head," Capacity "1"

• Number "104," Name "Wind," Code "Suite - Female," Capacity "4"

• Number "108," Name "Rain," " Code "Suite - Male," Capacity "4"

When you enroll residents into buildings and rooms, the number, name, capacity, and number of available spots remaining (or over) for each room is shown. Dorm group managers can manually assign residents of any number or gender to a room or building, regardless of how the building name, room number, room name, room code, and room capacity is configured.

Gender neutral terms are used by default, including:

• Spouse

• Ex-spouse/partner

• Parent/Guardian

• Student

• Candidate

• Child

• Sibling

• Grandparent

• Step-parent

• Cousin

• Friend

• Alum

Your school can create terms with gender specific name ("Dorm mother") when you clone an existing role and enter a new name for the role. However, a platform manager can assign the role to users of any gender, regardless of the role's gender specific name.

Your school can also activate terms with gender specific labels ("Husband - Wife") when your school sets up relationship types.

Gender appears in many "SKY" lists and also in advanced lists (an older or legacy type of lists).

Your school may learn the gender of other individuals in a user's family household when gender is included as a visible field in a school form. For example, you may learn the gender of someone's children if you include the User children block as part of a Profile update form.

However, since the user's own gender is not included as part of the User profile update block on a Profile update form, users can't update their own gender via school forms. Instead, they should access their profile directly to make changes.

Other forms--which are not officially known as "school forms"--handle gender in slightly different ways. For details, see the specific form type (such as for enrollment management).

Items in the school store may be designated as being designed for male, female, both, or N/A.

Users may purchase items with any gender designation, regardless of their own gender.

Most integrations will treat new gender values as Other (O) or Unknown/blank.

However, some integrations (including OneRoster, SAO) enable you to configure how gender values should be mapped.

See Integration mappings.

Be aware of how updates to Education Management may affect your current data management strategy.

• When gender values which are not male (M), female (F), or blank (unknown) are selected in Core, these other (O) or non-binary gender values are synced to matched user records in Raiser’s Edge.

  If the gender value doesn't yet exist in Raiser’s Edge, the Connect Raiser’s Edge creates a table value for the gender value and then links the value for the sync.

• Preferred pronouns in Core are not currently mapped or synced to Raiser's Edge.

• The single-select field for Ethnicity in Core still maps and syncs to Race in Raiser's Edge.

• The new multi-select field of Race in Core is not currently mapped or synced to Raiser's Edge.

• You must be on the latest patch Raiser's Edge 7 to handle non-binary gender values.

If your school submits data for the Wisconsin Information System for Education (WISE), gender values in Core that are not Male (M) or Female (F) will become None in reports for WISE.