Introducing Single Row Query in Blackbaud Raiser’s Edge NXT®: A Smarter Way to Export Your Data

David Springer · January 7

For years, database view Export has been the go-to tool for creating flattened data files in Raiser’s Edge NXT. It works, but it also comes with extra steps and complexity. That’s why we’re developing Single Row Query in Raiser’s Edge NXT web view: a streamlined, modern approach that combines the flexibility of Query with the simplicity of Export.

Why the Change?

Let’s look at what exists today in database view:

Creating an export often means building two separate items: a query and then an export.
Both Query and Export require similar steps, and learning the differences between them has caused confusion for decades.

With Single Row Query, you’ll be able to define your criteria and output in one place—no more hopping between tools.

What Is Single Row Query?

Single Row Query is our modern redesign of database view’s Export module. It appears as a result layout option in web view Query.

When you create a query, you’ll choose between:

Multi-row layout (the traditional query format)
Single-row layout (what you’ve known as Export)

The single-row layout flattens one-to-many relationships (like addresses, phone numbers, or gifts) onto a single row per record. This means cleaner spreadsheets and fewer headaches when preparing files for mailings, imports, or analysis.

Sample results for a single row query:

Key Benefits

Fewer Steps, Less Confusion: Everything happens in one workflow. Choose your layout; set your criteria, output, and sort fields; and you’re done.
Consistency and Flexibility: No need to learn two different tools. Single Row Query uses the same interface as Query, so you can apply filters, sort results, and even preview data before exporting.
Expanded Options: Because Single-row queries are still queries, you’ll also be able to include them in other capabilities. No need to run the export, then grab a separate query for a report. Just use the same query for both.
Performance Improvements: Web view queries often process faster than traditional database view exports, and results can be run or downloaded asynchronously.
API Access: Single-row queries will be available via API, enabling integrations with tools like Power BI and partner applications.

How Is It Different from Database View Export?

Unified Experience: Instead of creating a query and then an export, you simply select “Single Row” as your result layout when building the query.
Expanded Capabilities: You’ll have access to fields and features previously limited to database view Export, plus enhancements like working with results directly in the UI.
Migration Support: We’re building a tool to help you migrate existing exports to web view single-row queries.

When can I start using it?

Development is underway now. We’re planning early adopter opportunities in early 2026. Stay tuned for announcements, demos, and more as we near release.

Will I still be able to use database view Export?

Yes, for now. We know many organizations rely on existing exports, so we’re keeping them available during the transition. Over time, we’ll provide tools and guidance to help you migrate to Single Row Query.

Will existing exports migrate automatically?

No, but we’re planning a bulk migration tool to help you convert existing exports into Single Row Queries. Stay tuned for updates on timing and availability.

Can I still use one export with multiple queries (or vice versa)?

Yes! Using “Select from” functionality, which exists on the Options tab of queries today, you can set the criteria on one query, then use a second query for output. With this approach, you can reference the same base query for multiple single-row queries as needed.

“New query” modal, where you can select the result layout and “Select from” query:

Next Steps for You

Check out the Raiser’s Edge NXT Product Update Briefings here:
Raiser's Edge NXT® (North America)
Raiser's Edge NXT® (Pacific Region)
Raiser's Edge NXT® (UK & Europe)
Attend the new InsideTrack to the Unified View webinar series. The March session will be dedicated to Query & Reimagined Export in Web View
Share feedback, questions, and comments! We love to hear from you, and we’re building with your feedback in mind.
- Add comments on this blog post
- New feature requests can be submitted in our Idea Bank.

Bill Connors · January 7

Well written post, David, and an exciting change and potential improvement to the RE experience. I'm excited to see this and try it!

Lucy Ruiz · January 7

I am looking forward to working with the new functionality.

Dan Snyder · January 8

Can't wait to try this out!

Jen Cornell · January 8

@David Springer Where can I sign up for the Single Row Query EAP, if one is available?

Karen Diener · January 8

This is a little scary but I think it is a good move. I'll be testing it as soon as it is released!

Kelly Bodie · January 9

I think this is smart. Export has been my jam, but I'm the only one in my org who understands it. Reducing the tools will help, and I'm excited to try it.

Kate Sklodowska · January 13

So for now we will be exporting to Excel and csv. What about the other export options? I export 95% of my data to MS Access MDB files, mostly with one-to-many relationships. If you are not planning to allow for different export types, then I will need years to update our custom processes. Scary, but doable if given enough time.

Bill Connors · January 13

Totally agree, @Kate Sklodowska , I have often exported to both the flat and relational Access formats. Of course an Excel or csv file can be brought into Access with more work but at least it's do-able — doing so with the relational format would be a tremendous amount of work to re-create.

Irene Hui · January 15

So excited about this and can't wait to try it!

Elizabeth Johnson · January 22

@David Springer I am interested in exploring whether it is possible to selectively control the assignment of specific columns (such as phone types and solicitation codes) similar to the current export functionality. Also really curious how it will handle address fields and international configurations.

Emily Marshall · January 22

@Kate Sklodowska @Bill Connors, I asked about MDB format during the Nov 21, 2025, "Real Talk" Q&A with Blackbaud Raiser's Edge NXT Product Team" webinar from Prenger Solutions Group.

Me: "With Query Single Line, will we be able to export in Blackbaud Report Writer Database (MDB) format?" The response from @David Springer was "That's not planned currently. Our first goal is to get users the spreadsheet format they need from Export since that's how most users use it."

There is an idea in the Idea Bank, but unfortunately, there are only 5 votes and one supporting comment. Please vote if you haven't yet, if you have voted, please add a supporting statement on why blackbaud should include exporting to MDB format and how not having this file format available will negatively affect your work. Thank you https://renxt.ideas.aha.io/ideas/RENXT-I-8557

Bill Connors · January 22

https://community.blackbaud.com/discussion/comment/310066#Comment_310066

Thanks for the update and the idea link! I voted and added a comment.

Megan Tope · January 27

So, if I understand "You’ll have access to fields and features previously limited to database view Export" correctly, does this mean we'll now have access to all the fields that are available in an Export that are not available in a Query?

For example, in a Participant Export, we have access to a TON of Constituent fields that aren't available in a Participant Query, like assigned fundraiser, summary information fields, etc. With single-row query, would those fields become available to export directly from a Participant Query?

Jenn Watson · January 28

For my purposes, I only really need to use Export tool to get import ids for records that are NOT in the query fields. It would save me so much time/effort if those fields were in query, so have one place to do my export so I can keep up better on data hygiene tasks easier would be great.

Sarah Krenicki · January 30

This sounds so exciting! While the shift is certainly going to be a learning curve, I think this is a change I can fully get behind and believe it is a change for the better.

The only complication I can see so far is that I currently have some exports where I select from a constituent query, and then when exporting gifts, I am able to select gifts from a gift query(s). (Ex: the Query used for the Export is "2024 donors" and then I filter my export so that the only gifts getting exported are gifts present in the "Memorial Gifts" query. This way I have the names and desired info of ALL 2024 donors, but only want to see the gift details for the memorial gifts). I hope there will be a way to access this level of filtering in single-row!

Maura Carey · March 10

After attending the Inside Track session today, I am still confused about how we will use our existing exports. I understand that we need to migrate them. I am asking the question about after they are migrated. It sounds like you need to put the export in the Select From Query option. Will the "export" (which is now a single-row output query) include everyone in the database and the outputs will determine what information is extracted? For example, my query will be anyone who gave yesterday but my single-row output query will be everyone in the database with specific filtered output fields-does that sound correct? I think it would be very helpful to offer smaller training sessions for 50 people or less before the new "single row/multi row" option is released so that we can be better prepared for the transition.

David Springer · March 10

@Maura Carey , maybe an example will help…

In database view, I have an export called "Mailing List Export." It is currently selecting from "Mailing List Query" and includes extensive output fields (with additional filtering per field).

When I click the button to migrate my exports, the following will happen:

"Mailing List Export" in database view will not change.
"Mailing List Query" in database view/web view will not change.
When migration completes asynchronously, I'll have a new single-row query in web view called "Mailing List Export." This new query:
1. Will be selecting from the "Mailing List Query," so will include the same starting group of records.
2. Will include all of the same output fields with their existing filtering, so should output the same data in the same format.

The idea is that just by clicking the migration button, you'll have a new query for each export, which returns the same results. You could then add additional filters, fields, etc, to further build them out, but don't have to for the same results.

We're planning extensive documentation as well as trainings to go along with this change, so we'll continue clarifying plans and expectations before release.

@Sarah Krenicki , we're also planning to allow selecting from other query types just as Export does today.

Thanks, everyone, for the thoughtful questions and engagement!

Maura Carey · March 10

https://community.blackbaud.com/discussion/comment/311675#Comment_311675

This was extremely helpful! Thank you so much.

Sarah Krenicki · March 10

@David Springer

Thank you David! your explanation to Maura answered a lot of my unspoken curiosity/questions over how the migration will work as well.

I'm excited!

Lucy Ann Gossett · March 10

Thank you, David! The explanation was most helpful and appreciated.

Jenn Watson · March 11

I think this will be exciting to see when it is available. I don’t know if I have heard of how this is going to impact fields that are only in Query or only in Export.

I do not do a lot of exports myself. I use the long format from query the majority of the time because I do a lot of ETL work. I primarily only use Export when the import ID and a few other fields that I need are not available in query. I feel like I am doing at least double the work when I must use Export. I know exactly which emails I might need to update and can select only those emails for the constituent it belongs to in query. However, when I go to then export the information using the Export tool (only because I cannot get import id in query), then I have to filter down the results for the exact emails I need to update and then change the data back into a long format again for importing back into RENXT with the updated information.

It seems like with this update, that all fields including those that are unique to query and those that are unique to export, should now be in this one tool. I am really hoping this will save me time for my ETL processes.

Catherine Burns · March 13

Could the migration tool have the option of being run by Export folder instead of all at once? This might allow it to be rerun in a controlled way to limit duplicates e.g. a folder might not be able to be migrated twice, but if an export needs to be perhaps it could be moved into a new folder that has not been migrated.

We have several staff who use Export and because of workloads some will be ready to start working in webview before others. Those with heavy workloads when this becomes available will need to keep using database view which is familiar rather than have to learn the new web view features when they are up against data deadlines for important projects.

David Springer · March 13

https://community.blackbaud.com/discussion/comment/311815#Comment_311815

This is a good idea, Catherine! I'm curious - does it alleviate this concern since the database view exports will still be available? Meaning users who are ready could move to web view even before you click the Migrate button, just by creating new single-row queries. Then your organization can click Migrate when ready, and if any users aren't yet ready to move processes to web view, they can still use database view for urgent deadlines.

The one drawback I'd point out is that if they needed to make changes to exports, those wouldn't copy over to web view if the migration has already happened.

Catherine Burns · March 15

For us, with three main users of export, running by folder would alleviate the concern because we can manage which folder exports are in. In general, we use different exports so if they can be done at our own pace that helps. For shared exports, we have well documented processes that we can update to reflect migrated queries.