Query API Un-announced Change
I probably should report this through Support, but I know I'm not going to get far with that.
There appears to be an unintentional change or unannounced/intention change that is very bad in the Query API.
Query API used to send back data exactly how db view query would export the data. However, I just noticed that there is a problem with Gift Query > Gift Type.
It has been a delimma to say the least that Blackbaud decided to use different terminology for gift type 3 different way: DB view (Cash), Webview (One-Time Gift), and SKY API (Donation).
B/c of this, I created a Query API that export the database view's gift type and it was working great by giving me “Cash” instead of the other 2.
However, I just checked my Query API data, and I am seeing a problem where SOME gift type was changed.
| Database Gift Type from Query API |
| Stock/Property |
| Pay-Stock/Property (Sold) |
| Recurring Gift Payment |
| Write Off |
| Matching Gift Pledge Payment |
| Recurring Gift |
| Matching Gift Write Off |
| Pledge |
| Pay-Gift-in-Kind |
| Planned Gift |
| One-Time Gift |
| Pay-Stock/Property |
| Other |
| Matching Gift Pledge |
| Pledge Payment |
| Gift-in-Kind |
| Stock/Property (Sold) |
You can see this is going to be a big problem……………… CAN you please get some eyes on this and resolve.
Comments
-
Hello, @Alex Wong. I hit this issue too. The update announcement was published today, dated 9/16/2024: https://developer.blackbaud.com/skyapi/support/changelog/renxt
0 -
@Rebecca Sundquist
not likely this ……0 -
@Rebecca Sundquist
not likely this ……The changelog mentions that there was some updates about the outputs of Gift types to be more in line with the WebView . Are you seeing changes not mentioned there?
1 -
@Glen Hutson @Erik Leaver @Alyssa Maslankowski
I notice the issue before the announcement was made. However, even with the announcement, I think this is a mistake on BB's part to just change the exported data from Query API. Since Query API is already in production use, making this kind of incompatible change would have been consider a regression in the world of programming.BB should instead add an option to the Query API endpoint to use webview labelling or dbview labelling. and default should be dbview labelling as it was how Query API was originally.
I understand why, as I mention in the PA User Group, as to likely b/c BB is trying to make user, who may not have ever used dbview, less confused with difference in labelling from the webview's label. All the more reason why Query API shouldn't have introduced a regression, rather a new feature that allows for webview labelling that the Query on the webview can use.
1 -
Now, I can ONLY PLEAD that BB does not sudden decide to “align” all gift type terminology and change the gift type being returned by Get a Gift and Get Gift List API endpoint, there are WAY TOO MANY automation and reporting that already align to the terminology used (Donation instead One-time Gift NOR Cash)
2 -
@Alex Wong, I apologize that the change went out ahead of the announcement. It certainly wasn't our intent to break established processes, and this was obviously a miss. Thanks for calling it out, and I'll work with the other product managers to ensure we're properly announcing any further changes ahead of time.
To your point, we're seeking consistency of terminology across parts of the system, but I like your idea of a sort of “compatibility mode” to use DBV or web view language for gift types.
Is the primary need for compatibility mode with gift types, rather than the column headers that were changed at the same time (Attributes > Custom Fields, Proposal > Opportunity, Solicitor > Fundraiser, etc)?
0 -
@David Springer
My primary concern is with the naming change of gift type, however, that that's represent all that may have issue with this change.If you are to consider the “compatibility mode”, may want to have this mode applies to all naming.
0 -
@David Springer
I had the same concern as Alex during your webview query demo today.Not only for SKY but once fully in webview as well. Some files are exported, validated by users and then get processed via applications I've written. These applications depend on current database gift-type naming convention.
Perhaps utilizing user options to change how gift-type fields output. This would be similar to how short and long description can be adjusted currently in database view
0
Categories
- All Categories
- 6 Blackbaud Community Help
- 213 bbcon®
- 1.4K Blackbaud Altru®
- 401 Blackbaud Award Management™ and Blackbaud Stewardship Management™
- 1.1K Blackbaud CRM™ and Blackbaud Internet Solutions™
- 15 donorCentrics®
- 360 Blackbaud eTapestry®
- 2.6K Blackbaud Financial Edge NXT®
- 655 Blackbaud Grantmaking™
- 576 Blackbaud Education Management Solutions for Higher Education
- 3.2K Blackbaud Education Management Solutions for K-12 Schools
- 939 Blackbaud Luminate Online® and Blackbaud TeamRaiser®
- 84 JustGiving® from Blackbaud®
- 6.6K Blackbaud Raiser's Edge NXT®
- 3.7K SKY Developer
- 248 ResearchPoint™
- 119 Blackbaud Tuition Management™
- 165 Organizational Best Practices
- 241 Member Lounge (Just for Fun)
- 34 Blackbaud Community Challenges
- 34 PowerUp Challenges
- 3 (Open) PowerUp Challenge: Chat for Blackbaud AI
- 3 (Closed) PowerUp Challenge: Data Health
- 3 (Closed) Raiser's Edge NXT PowerUp Challenge: Product Update Briefing
- 3 (Closed) Raiser's Edge NXT PowerUp Challenge: Standard Reports+
- 3 (Closed) Raiser's Edge NXT PowerUp Challenge: Email Marketing
- 3 (Closed) Raiser's Edge NXT PowerUp Challenge: Gift Management
- 4 (Closed) Raiser's Edge NXT PowerUp Challenge: Event Management
- 3 (Closed) Raiser's Edge NXT PowerUp Challenge: Home Page
- 4 (Closed) Raiser's Edge NXT PowerUp Challenge: Standard Reports
- 4 (Closed) Raiser's Edge NXT PowerUp Challenge: Query
- 791 Community News
- 2.9K Jobs Board
- 53 Blackbaud SKY® Reporting Announcements
- 47 Blackbaud CRM Higher Ed Product Advisory Group (HE PAG)
- 19 Blackbaud CRM Product Advisory Group (BBCRM PAG)



