Logic field for Nickname/Firstname in Official Notes

In Core, under User Name Format, Blackbaud gives us a useful placeholder which gives the nickname (preferred name) if there is one; otherwise gives first name.

However, within Official Notes, the only fields available to us are First Name OR Preferred Name. This causes a real dilemma, because if we want to personalize our official notes using a person's preferred name, there's really no way to do this, since many preferred name fields are empty. We are forced to keep our communications formal, using their NOT-preferred names, because we are not given a viable option for addressing the users in these communications.

One of the reasons we loved Blackbaud so much was because many of our users have nicknames and our old database forced us to have impersonal communications. We had the distinct impression that Blackbaud honored people's preferred names. I'm really hoping that this logic field, which chooses the first name when there's no preferred name, can be placed in all areas of communication such as Official Notes.

Thank you for considering it!

  • Tamara Photiadis
  • Nov 18 2021
  • Implemented
  • Attach files
  • Admin
    Kelsey Huijgen commented
    17 Apr 05:00pm

    Hi Dino - thanks for pointing that out! I updated the title for this idea. There is already a separate idea for updating the name format in Conduct, which you can vote on here: https://blackbaudk12.ideas.aha.io/ideas/K12OR-I-762.

  • Danielle Keeney commented
    17 Apr 11:45am

    Was the solution implemented for just Enrollment Management Official notes or also Academics Official Notes?

  • Dino Vandenheede commented
    16 Apr 08:42pm

    Does this mean I need to start a new idea for "Logic field for Nickname/Firstname" with the Conduct Manager? The idea title is for "All Communications."

  • Admin
    Kelsey Huijgen commented
    16 Apr 08:31pm

    Hello! We recently updated the preferred name placeholder in Official Note templates so that it follows the "preferred else first" format. You can now use that placeholder to pull in the preferred name for any student who has one, and it will default to the first name for anyone who does not have one. I am going to close out this idea since Official Notes in Enrollment Management have been updated, but please submit new ideas for anywhere else in Enrollment Management where you'd like to see this change!

    Kelsey Huijgen, Product Manager

  • Dino Vandenheede commented
    15 Apr 07:46pm

    I noticed that if I used "Preferred Name" with Conduct emails, the system will NOT put in the first name if the preferred name is blank. So, we had to use First Name.

  • Tamara Photiadis commented
    18 Jan 03:12pm

    It seems that this idea has been mostly implemented. I had an exchange with tech support where they confirmed that, any place where [preferred_name] is used, if the field is blank, then it automatically pulls from [first_name]. It is not THOROUGHLY implemented...it's not there yet with Event Management, nor with some areas of SIS (school forms? I don't remember). But most of Enrollment Management has this functionality. We have tested it and found it to be so.

  • Guest commented
    27 Sep, 2023 12:45pm

    The first name shows at the top of the official note email and this confuses staff who know the student by their preferred name.

    In addition the author shows by first name and would like to show by preferred name in the email that goes out for the official note.

  • Melissa Battis commented
    16 Nov, 2022 03:41am
  • Tamara Photiadis commented
    29 Nov, 2021 05:44pm

    It has been suggested that we manually fill in the "preferred name" field for all users as a way to handle the limitation currently existing. The problem with doing this is that it takes away the visual flag of nickname in an auto-generated list. When a list of names in generated, you can see right away which candidates go by a nickname because of the quotes. But if you fill in every "preferred name" field with the first name, then every name has quotes. It gives you a technically correct list, but it eliminates the human factor, which is to make it easy to identify the exceptions. Not to mention, how much work will it be for all your clients to correct the data in this field once it's use is corrected?