Duplicate handling with Constituent API

Amy Sewell

Hello -- 


Is there a good way to handle duplicate record management within the Constituent API?  We currently take transactions via Online Express and then push into RE and there's a matching process to help merge records likely to be the same person.  As we switch to taking donations through our website via API I'm curious if this process is still available or if there is some other way to handle merging records so that we avoid a significant amount of duplicate records in our RE database.  


Thanks!


Amy

Alexia Chapparone

Blackbaud SKY API‍ Blackbaud Developer‍ could you provide any insight to the post below? 

Ben Lambert

Hi Amy,


At the moment, we don't expose any duplicate record management functionality through SKY API.  You can however leverage the existing endpoints that fetch constituent details (name, address, email, phone, etc) and perform whatever duplicate matching logic you need on your end within your code.


That said, if you have any thoughts about what we could provide from an API perspective that would help with managing duplicate records, please let us know.


Also, just to mention it...Raiser's Edge NXT has built-in duplicate detection logic that runs continuously every 15 mins or so.  Any duplicates found will be shown in the Tools -> Data Health page, where you can review/resolve as needed.


Hope this helps - please let us know if you have any questions!

 

Alex Bridge

Hi Ben Lambert‍,

if you have any thoughts about what we could provide from an API perspective that would help with managing duplicate records, please let us know

I'm not the original poster, but I'm currently working on a similar integration where being able to identify duplicates would be useful. As this would be primarily for deciding whether to create a new Constituent record or to make use of an existing one, I think an endpoint that accepts the same (/a similar) request body as CreateConstituent would be simplest: this would return likely matches with a confidence score, or a response indicating that no matches were found. In the case where there are no matches (or no matches with a high enough confidence), the request body could then be immediately reused to create the Constituent.

Ben Lambert

Hi Alex,


Thanks for this feedback!  We are discussing whether/how we can surface some APIs to help with your scenario.  Nothing is committed and no ETA to share at this point, but this feedback has been very helpful in those discussions


Thanks!

Nathan Wells

Any update on this Ben Lambert‍ ? I'm also trying to figure out the best way for new/update constituent.


Right now I'm thinking we try to lookup a constituent via email, loop through to check if it matches the name, and if there are no matches, then we create a new constituent, but if there is, then we just use that ID for whatever we were doing.


But it still is possible we would create a duplicate (new email address, but same person)...so not sure the best way to deal with that.

Ben Lambert

Nothing new to report on this I'm afraid (but glad to hear thoughts on how you'd like this to work so I can route this to the appropriate team within Blackbaud).

Nathan Wells

I guess it would be nice to expose the automatic matching system that exists https://event.on24.com/eventRegistration/console/EventConsoleApollo.jsp?simulive=y&eventid=2613652&sessionid=1&username=&partnerref=&format=fhvideo1&mobile=&flashsupportedmobiledevice=&helpcenter=&key=A2E1BD9D112A131582CAEF0014CFA291&newConsole=true&nxChe=true&newTabCon=true&consoleEarEventConsole=false&text_language_id=en&playerwidth=748&playerheight=526&eventuserid=444804945&contenttype=A&mediametricsessionid=385016030&mediametricid=3684943&usercd=444804945&mode=launch


That way we can just easily add/update a constituent and not have to worry about doing any checks ourselves but just use the system that already exists.

So we submit the user's info, and if there is not match, a constituent is created, and if one does exist, their info is updated. And the response would be that constituent's id so we can store that for later use.


The issue for us is we are building a new donor portal, so users are creating new accounts on the portal and we are then trying to match them up with their existing constituent id so when they make donations etc. it can be correctly matched in RE. Ben Lambert‍