nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Preferred addresses that are actually bad addresses

Peggy Dolter

We just converted to RENXT about six months ago — I don't mean from RE, but from an entirely different system.

We've been getting a lot of returned mail. Users are creating web view lists to generate mailing lists. This means that the preferred, starred, address is always selected.

For some constituents, though, we don't have any good mailable address at all. Their bad address (lost, deceased, omit-from-mailing) is only marked as preferred because the software requires constituents to have a preferred address.

It would be better to see a blank address, rather than a bad address.

So I think I should export all the preferred addresses, using database view so I can include the address type -- That way I can see which constituents should never be sent mail (lost, deceased, omit-from-mailing). For those constituents, I will import new blank addresses that are marked as preferred.

I don't want to delete the bad addresses (for historical purposes). But my aim is to push the bad addresses out of the way, so that the web view's lists won't make it seem like they are mailable addresses.

And this should only take a fraction of the time that would be required to train users to export from database view.

This should work, right?

Find more posts tagged with

Query Import Export

Accepted answers

All comments

Tatyana Leifman

If the deceased are so marked, then users should be trained to exclude them from their lists (I believe some default settings in NXT/WV already do that).

There is also the "Mark Do Not Mail" button for an address. And an address can be both preferred and Do Not Mail at the same time. Again, users should be trained to exclude addresses marked "Do Not Mail" from mailings.

The problem with having a blank preferred address is that inactive addresses are not immediately visible when a user opens the record. One has to actively click on several buttons to check for inactive addresses. And from personal experience, I can tell you that despite the ease of NXT in its WV version, users will not check for inactive addresses. And so you risk addition of duplicates or the same bad address to be added back in as the preferred address or misidentification/non-identification of donors or relationship that should be linked.

Just my 2 cents.

Carlene Johnson

Long post ahead — I’m sharing a full explanation and resource list so this thread can serve as a reference for others down the road. (I'm also very passionate about this topic and got hyper-focused!)

I completely understand the frustration with returned mail. But creating blank preferred addresses to “push aside” bad ones is not a safe or sustainable solution, and it will cause significant long‑term data quality issues.

RENXT/RE is built on the assumption that every constituent will always have a preferred address — even if that address is coded as Do Not Mail, Invalid, Lost, Previous, Deceased, or whatever terminology your organization uses. The system expects users to exclude non‑mailable addresses when generating mailing lists, not to hide them or overwrite them with blanks. Introducing blank preferred addresses breaks that logic, interferes with Address Processing, and ultimately makes the data harder to manage and more prone to errors.

1. Lists in Web View are not designed for mailing production!
Lists always pull the preferred address and cannot filter on “has no valid address,” which is exactly the scenario you’re trying to manage. This is why Lists produce misleading results.

Mailings should be generated using:

Query (Web View) + Export (Database View)
(Export is coming to Web View, but not yet)
Address Processing, which applies all address rules and ensures only mailable addresses are selected

Or at minimum, export the preferred address after excluding anyone with no valid address.

Address Processing evaluates seasonal, preferred, alternate, and attribute‑based addresses and determines whether a valid, mailable address exists. If none is found, it can automatically exclude the record from the mailing — exactly as designed.

Query and Export both allow you to easily exclude Deceased, Inactive, or Has No Valid Address with a simple checkbox, and Export handles Household logic correctly.

2. Address Processing exists specifically to prevent returned mail
Address Processing is the engine that determines which address should be used for any mailing, report, or export. It evaluates:

Seasonal addresses
Address types
Address attributes
Do Not Mail flags
Lost/invalid/previous addresses
Contact logic for organizations
Fallback rules when no valid address exists

Lists bypass Address Processing entirely, which is why they cannot reliably produce mailable output.

3. Blank preferred addresses create more problems than they solve
If you import blank preferred addresses:

Bad addresses could be re‑added as preferred
Address history becomes unclear and unreliable
Users won’t see the inactive/bad address without digging
A blank preferred address can cause Address Processing to stop before it can evaluate the inactive/bad address or check for any other viable options — like a seasonal or business address — so the system never completes its full review.

This workaround undermines the system’s design and increases the risk of bad mailings.

4. Training users is easier than cleaning up the fallout
It may feel faster to engineer a workaround, but you’ll spend far more time later fixing duplicates, restoring preferred addresses, correcting relationships, and re‑training users anyway.

A short training on “Mailings must be built from Query/Export + Address Processing, not Lists” is far more effective and aligns with how the software is intended to function.

Further Resources
These resources reinforce the correct workflow and explain how RE determines which addresses are mailable.

Product Documentation: Addresses in Raiser’s Edge NXT
This is Blackbaud’s current, authoritative documentation on address fields, preferred address logic, seasonal addresses, and how RENXT handles address selection.

Query Criteria: Has Valid Address / Deceased / Inactive
How RE determines “Has No Valid Address” and how to use it in queries:
Records are marked as Has No Valid Address
What is the Has No Valid Address checkbox?

Mailing Best Practices (Highly Recommended)
@Bill Connors’ guide to Getting the Best Success with Mailings from RE
(Older, but still one of the clearest explanations of how RE mailings are designed to work):

Idea Bank Request
Finally, for anyone following this thread, there’s also an Idea Bank request to add a ‘No Valid Address’ filter to Constituent Lists

Note: I asked Copilot to help me organize and format the points in this post for clarity.

Karen Diener

Just read Carlene's post. She's said what needs to be said.

Carlene Johnson

https://community.blackbaud.com/discussion/comment/309860#Comment_309860

I'm impressed you made it the whole way through! 🤣

Bill Connors

Great job, Carlene! Thanks for the shoutout on the resource as well, which to this day is just about as applicable as it was years ago when it was created. Two additional thoughts:

On your 1. above: mailings should be done from Query + MAIL, not Export. :) Only use Export if Mail truly cannot do what legitimately needs to be done.

Another reason for not removing bad addresses from the Preferred address is that every copy of NXT comes with an AddressFinder subscription for NCOA. That works on your having and providing the last address you have for that person, and it needs to be the Pref address. If you want to find them, you need to leave the address there.

Thanks!

Carlene Johnson

https://community.blackbaud.com/discussion/comment/309875#Comment_309875

Excellent point, Bill! I've fallen out of the habit of using Mail and tend to export as my default, but Mail has a ton of fantastic features that shouldn't be overlooked.

It will be interesting to see what, and in what manner, different pieces of Mail functionality are brought over to the Unified View.

Peggy Dolter

Wow, thanks for the helpful feedback, everybody. I'm learning! So…

We could have a static query that selects all living constituents who have a preferred address that is "Home" and doesn't say "do not mail". Then, the training required within our department is twofold:

For me: Run that dang static query once or twice a week. (We are so small that I think this would be often enough)
For a user who doesn't know database view: Anytime your constituent list is going to be used for mailing, build your list off of that static query.

Now, that should work… right?

Jumping in as RENXT users while the company is in the middle of moving to unified view is interesting; everything is a moving target. I just hope the unified view will have all of the same filters and columns that are in database view.

Jack Briggs

Among our (dynamic) maintenance queries, we have some that scope for (in)valid addresses, based on e.g. "Address Line1 blank" AND "No Valid Addresses? equals No" and similar combinations, to weed out the non-addresses. Something like that might be easier. You could do one big clean now then just run those maintenance queries once a week.