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
Related ideas
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.
Attachments Open full size
Was the solution implemented for just Enrollment Management Official notes or also Academics Official Notes?
Attachments Open full size
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."
Attachments Open full size
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!
Thanks,
Kelsey Huijgen, Product Manager
Attachments Open full size
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.
Attachments Open full size
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.
Attachments Open full size
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.
Attachments Open full size
This is important as can be seen in the following similar ideas, some of which date back to 2015: https://blackbaudk12.ideas.aha.io/ideas/K12CO-I-3427
https://blackbaudk12.ideas.aha.io/ideas/K12OR-I-2639
https://blackbaudk12.ideas.aha.io/ideas/K12CO-I-1329
https://blackbaudk12.ideas.aha.io/ideas/K12OB-I-416
Attachments Open full size
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?
Attachments Open full size