Stop including deceased users in group "Send Communications" lists.

The title speaks for itself.

I have been told by support that:

"There's another thing that I wanted to clarify which is not clear on the documentation, is that even if you hide the deceased user from the student's contact card, if they still have the Parent relationship with that student, they will be included in the "Send Communications" feature regardless.

"Removing their email/disabling Inbox notifications in the notification settings will cause this messages to lead nowhere as no one will get notified. The only way to exclude deceased parents from receiving these messages is by removing the Parent relationship from the student, unfortunately."

Removing the parent relationship undermines Blackbaud's role in being our SIS and system of record.

While we can minimize the communication by manually turning off the notifications for in-system messages, we cannot prevent group leaders from using the Send Communications feature to generate a list of emails to paste into their email client (as is normal in our school) that would include the deceased parent.

In addition, the documentation for managing deceased users does not include this information, and the instructions for marking a user deceased do not reference the fact that there is a more complete (but still incomplete) page of related documentation.

Immediately: update documentation.

In short order: stop including deceased users in "Send Communications" lists.

  • Seth Battis
  • Apr 16 2024
Employee Name Seth Battis
User System Admin , IT Admin
  • Attach files
  • Seth Battis commented
    18 Apr 12:58

    The coda to my ticket about this (not to turn this into a personal grievance session, but simply to highlight an important issue with the work-around suggested and to raise a question about the distinction between a bug and feature request):

    If a teacher chooses to use the Send Communications feature to generate a list to email, if the deceased parent has an email address in their records, then yes, they will be included.

    Unfortunately, I've checked with my internal team already and this isn't classified as a bug on our end since the "deceased" indicator simply isn't programmed to remove the users from communications. I sincerely apologize, once again, for the inconveniences.

    My response, which was not delivered, because the ticket had been closed:

    For our purposes, it makes a lot more sense to delete the email/phone/address of the deceased than to delete the relationships, which we believe should have the same impact. (You can’t include an email that’s not there.) Preserving the relationship data is VERY important in terms of maintaining a CRM/SIS.

    I understand that from your perspective, this isn’t a bug because there’s no broken code. Just a lack of code.

    That said, I absolutely defy you to come up with a reasonable explanation of why we would want to communicate with dead people, and — given your own documentation in that regard — even more so to explain why we would want to cause distress to their families by doing so. A bug can also exist in the void left by missing code.

    The proposed work-around (deleting relationships) is more destructive than what we chose to do (delete contact info). We're unlikely to really need that contact info again (although it would be useful to have it in the system for historical searches). We are very likely to need that relationship info again and immediately.

    The inconsistency of behavior, combined with the incomplete documentation of that behavior, is the bug. It's like saying that you weren't lying when you didn't tell me. It is a bug of omission, if you will.

  • Jeanne Townsend commented
    16 Apr 15:31

    Agreed wit @SethBattis that we should be able to keep students connected to their deceased parents with the appropriate relationship (Parent) and that the system should respect the Deceased flag accordingly to remove deceased users from all communications and notifications.

    And better documentation...always!