BBID lost when merging records in Core

We have quite a few alums in our system who fill out inquiries and applications for their children. When they do this, a duplicate record is sometimes created. On the Merge Duplicate Records screen, the alumni record is retained which makes sense as it often has quite a bit of information tied to it. We can choose to update some of the fields on the old record with new information from the duplicate record. Unfortunately, we cannot choose which username is kept. It forces us to keep the legacy login, which obviously does not work as it is not a BBID and is most often also disabled. We would love to have an option to keep the newly created BBID in these instances.

How are others handling this?

There are a couple of ideas in the Idea Bank that address this issue: K12CO-I-3015, K12CO-I-3232, K12CO-I-1557.

Comments

  • @Nancy Kierstead, this situation has ignited a “strategic” fire in my school: When alums revisit the school as Parents of Candidates, the question of whether to preserve the new [parent of candidate] login or the existing [alum] login, one has to ask whether alum records should be in Education Management (BEM) in the first place.

    An old sage engineer I knew from long ago once proclaimed, “If information is in two or more places, it's probably wrong in at least one of them.”

    With this in mind, we're thinking seriously of allowing any alum records that we currently have in BEM go dormant and do all of our alumni biz where it probably should be done: in Raiser's Edge.

    That said, having that alum revisit us as a parent provides the service of rereshing info in RE.


  • @Nancy Kierstead @Lauren Marcus Eisenberg @john ronan - So here we are a year later… I noticed that https://blackbaudk12.ideas.aha.io/ideas/K12CO-I-1557 from 2016 was marked as “planned," but I guess it became unplanned. Our database manager/admissions assistant is getting very disheartened that users' BBIDs are getting lost when she needs to merge records in EM or Core. What is worse, is it gives the user who needs to recreate their BBID the impression that the school does not know what it is doing. “I just created that last week. Why do I need to do it again?”

    As it was explained to me, the system creates a user when someone sends an inquiry. This user has data but no BBID. When that person chooses to apply, it then creates another record with a BBID. When these two records are merged, the BBID disappears and cannot be preserved. I am not sure if we have a setting incorrect somewhere that will prevent this. If we do, please let me know so it can be remedied or if you have found a “work around," we would love to know the process. The fact you cannot keep a BBID intuitively when merging records seems poppycock to me.

    Scott

  • @Scott Chrysler I've definitely experienced the issue of BBIDs being removed when merging parent accounts but I think there might also be a partial solution based on the workflow you're describing.

    We have a similar approach in terms of not automatically generating BBIDs from inquiry submissions but I do go through the bulk BBID creation for parents of candidates for the start of the admissions season and then periodically as the season progresses. This prompts parents to set their passwords and start the application, removing the need for them use the self-service account creation process and (usually) helps prevent the need to delete/merge accounts.

  • @Troy Burki - Thanks very much for your process. I will pass this along to our admissions team as way to avoid this issue. Another creative work around provided by users to compensate.

    Scott

  • @john ronan I understand the questioning of having your alums in two places, but if they aren't in Core then you can't find legacy kiddos, can you? I am currently in the process of having our alums added into Core and we plan to utilize Connect RE….the goal is to prevent manual importing of new families into RE, but also for connecting our students to their alum parents….do you use Connect RE?

  • @Chrystalle Kiefer We do use Connect/RE. (C/RE)

    We have trying to get our advancement office to completely embrace Raiser's Edge for all of their work. This way, they can seamlessly use the [rather robust] email system in RE for both current students/families and alums. In the past, they would use Core for current families and RE for others. [YUK, as far as I'm concerned]

    In order to do this, we introduce families (i.e. parents and students) to RE as soon as they enroll using C/RE. A [useful] side effect of this is that any new-to-Core parents of incoming students will be linked to their alumni record in RE if applicable and duplicates are avoided, etc.

    As a result, the Advancement Office can go to RE and find current student children of alums, etc.

    Admittedly, it's not a given with this approach that Core can be used to find children of alums, but kids could easily be tagged somehow when they come in. [special role? custom field? ]


  • @john ronan Okay, thank you!! My admissions team doesn't have access to RE and they are often looking to find legacy kiddos…that is why I asked. Thank you for your response!! Have a wonderful day :-)

  • @Nancy Kierstead
    I manually delete the duplicate record. First I update the one with the userid with any missing information. Then I delete the record I don't want.

  • @Ellen Gershman
    This is how I handle it as well if the one without the BBID login does not have much info attached. Often, however, the one without the BBID is an alum, a pending faculty member, a current parent, etc. I don't want to delete the record with attached forms, documents, transcripts, etc.

  • @Nancy Kierstead and @Ellen Gershman - Is it just me or is this crazy to have to do to merge records? This is a pretty basic need in a database. I appreciate people creating another “workaround” for a Blackbaud foible, but merging records WHILE maintaining a user's BBID should be a fundamental functionality of the system - in theory.

    Scott

  • With all due respect to the implementers, it would be extremely useful to allow discretionary merging as in RE. [i.e. users can choose when to merge and which “way” the merge should go. [i.e. which record is kept and which deleted]].

    [There's an idea out there titled “Merge Users Option” that's gotten hundreds of votes….?]

  • @john ronan - Is this the one you were referring to?

    https://blackbaudk12.ideas.aha.io/ideas/K12CO-I-115

    The one with 212 votes that was created 8 years ago? ?

    Scott