Best Of
Re: NEW GRANT SET UP
You have to link a transaction code value to the Grant Record. This means you should have 1 of your 5 potential categories of transaction codes defined as Grant, and a table entry there. To link it to the grant record, you'd go to the transaction code field on it and pick the table entry setup for it. It's the table entry that is used in any transaction, not the Grant Record.
Introducing the Raiser's Edge NXT Prospect API
The Prospect API is now available in public preview for Raiser's Edge NXT. With this API, you can:
- Retrieve and update prospect records to keep cultivation data current across integrated systems.
- Track prospect status changes to automate workflows and trigger timely outreach.
- Monitor cultivation stages to measure pipeline progression and forecast fundraising revenue.
Re: Regarding usage Gift lists and Constituents.
Use Query on Webview will allow far more filtering and output
Re: call_dialer and automated_email in school/v1/users/emergencycontacts/changed
I'd say, for standard school integrations, No. That field is either no longer is use, or was never in use. It was intended only for partners that robocall users. Legacy partner integrations, at that. If you are working with a school actively using one of those partners still, then they might care about that field.
I don't have a way to tell why their data is a mix of values.
Re: RE NXT and Merchant Services
Hi @Barbara Sauber - happy to chime in to help. I'm cutting and pasting a bunch of information from an idea I have in the idea bank.
Yes, you're definitely not alone on this one, it's a common complaint and honestly a frustrating one. And just to be clear on terminology: what you're running into isn't AddressAccelerator, it's a completely different tool. This doesn't have anything to do with Blackbaud Merchant Services either, but rather Blackbaud's forms. What's actually happening is that Blackbaud uses a geolocation/places autocomplete service (like Bing Maps Autosuggest) for gift forms, event registration, constituent forms, or manual record entry.
That tool is built for map searching, not for validating mailing addresses. As a result, it frequently:
- Fails to recognize valid residential or organizational addresses
- Suggests unrelated businesses or far-away locations
- Struggles with international formats
- Doesn't standardize addresses to USPS or global postal standards
- Creates friction for donors, registrants, and staff
- Introduces inconsistent or undeliverable address data into the database
For a fundraising CRM, accurate and standardized addresses are essential for stewardship, tax receipts, segmentation, and donor communication. A mapping autocomplete just isn't built for that job.
The idea I submitted to the Idea Bank asks Blackbaud to replace the current geolocation-based autocomplete with true postal validation — USPS CASS-certified for U.S. addresses, and a global postal dataset for international ones — applied consistently across every address entry point: RENXT Standard and Optimized Donation Forms, Event Registration Forms, Constituent Forms, manual entry in NXT, Membership Forms, and any future forms or workflows that collect addresses.
The benefits are pretty clear: cleaner data at the point of entry, fewer returned mail pieces and wasted postage, a better donor/registrant experience, higher conversion on forms, less reliance on batch cleanup, and more accurate reporting and segmentation.
Barbara, your current addresses are very likely more accurate than what's coming in through the new form, since that process strips out Apt, Ste., or Unit #.
In the meantime, you've got a few options related to Online Data Review:
- Review and match all transactions — manual review of everything before it moves to batch. Full oversight, but it'll slow down processing considerably. Worth it if you need hyper-accurate data or handle sensitive information.
- Review transactions with unmatched constituents only — lets the system auto-match high-confidence constituents and only flags unmatched ones for review. Faster, but it won't catch an address mismatch on an existing match — you'll end up with two "Home" addresses, with the new one marked Preferred. You'll need to run audit queries periodically to sort those out.
- Set forms to bring in new addresses as "Online Form Address" type, then review periodically against the existing address on the record. This is the system Elizabeth Johnson follows.
- For larger organizations, building an automated solution with Power Automate may be worth exploring. Austen Brown, you might have some thoughts on that approach.
Options 2 and 3 can work fine for smaller organizations, but they're not realistic at scale for larger ones.
One last thing on AddressAccelerator: Blackbaud is working to bring AddressAccelerator into Web View — it's currently a Database View-only add-on, so not every client even has it. When you run it today, it adds attributes directly to the record flagging the specific issue with an address. My concern is that when it comes to Web View, it'll follow the same pattern as Address Finder there now: results surfaced in a list inside the Data Health tool, but not written to the record itself, and not something you can query or export against. If that's the direction it goes, we lose the ability to actually act on that information at any scale, which would be a real step back from what AddressAccelerator gives us in Database View today.
Barbara — if any of this resonates, please go vote on these related ideas. Votes are how Blackbaud actually prioritizes what gets built:
- Create better address validation for NXT forms — directly addresses the unit/apartment number stripping issue you're running into
- Address Finder needs AddressAccelerator Footnote — speaks to the concern that Address Finder results aren't writing back to the record in a queryable way, which is exactly what worries me about how Accelerator might land in Web View
- Replace geolocation autocomplete with postal validation — my idea on swapping the current mapping-based autocomplete for true CASS-certified validation
I hope some of this lengthy response makes for some good discussion and more votes in the Idea Bank!
One way I use the APIs - People Lists
Many of the programs I wrote that use the Blackbaud School API also use APIs for other services. That allows me to extract information from the SIS and use it to update other systems or files.
One of the most useful projects is the People Lists spreadsheet. We’re a Google school so we have many files shared to employees. One of the requests that I used to get a lot was for lists of various subsets of students: “Can I get a list of all of the 7th grade students with their advisor’s name?” “I need a list of all of the Middle School Boarding students.” Etc. Etc. Etc.
I wrote a program that uses the Blackbaud School API to read information about all of our students, and then wrote that information into a shared Google Sheets file using the Google APIs. There are sheets for All Students, US Students, MS Students, Residential Students, Day Students, and one for each grade level. It includes information that employees have access to through the LMS, but in a form that makes it easy to access.
The spreadsheet also includes a list of all employees, and lists of MS and US advisors.
The program runs as a scheduled task once a day, so the information is always up to date.
Most employees remember that the file is available to them. I sometimes get a request for a list, and I just reply with information about where to find the file. It has saved me a lot of work because I don’t have to generate the lists every time someone asks for it.
Re: DBV to NXT Recurring Gift Conversion
We had the same problem recently. And as you did ended up removing the appeal end date. I hope a better solution comes soon.
Blackbaud eTapestry® Product Update Briefing: Leave Feedback and Earn a Badge!
Blackbaud’s Product Update Briefings are coming up November 18-20. These sessions highlight the latest updates and give a sneak peek at what’s coming next, including features based on ideas from our awesome community! Sign up today, watch the briefings, and let us know what you think, what got you excited, or any other thoughts related to Blackbaud eTapestry.
Bonus – if you leave your feedback, you'll snag our exclusive special November challenge badge!
Re: call_dialer and automated_email in school/v1/users/emergencycontacts/changed
The field is in the Post endpoints for emergency contacts.
It's not a field in the Import.
Maybe they had the install at one point that was actually uninstalled.
If they don't have access to the field now via UI. The only way to manage it is by API calls - set it in a Post and retrieve it with a Get.
Re: How to handle recurring gifts set up during appeal
A couple of years ago we moved to transacting the first gift against the source appeal and then moving it over to a common Monthly appeal after. We had gifts transacting against their 20 year-old appeal, so that appeal could never close and that created a lot of noise. And a unique-to-us setup to support financial reconciliation made it really hard to reconcile between fundraising and financial reporting.
This hasn't come without challenges because of how RE lets you access data - why can't we get the recurring record ID when querying the recurring pay-cash? We have to use the import export to link gifts for reporting on a specific campaign for multi-year analysis and you can't get the import export from queue so it has to be manually run every time.