While similar filtering can be achieved through Queries, the key value of this functionality is having it available directly within the constituent record, where Fundraisers and Relationship Managers do much of their day-to-day work.

For example, users could configure their tabbed views to automatically filter out Admin/Operations Notes or Actions, leaving a cleaner, more relevant view focused on relationship management activity.

Requiring users to build and run separate Queries achieves a similar data outcome, but it does not improve the experience while actively working within a constituent record. Bringing this capability into Lists would allow users to tailor their constituent view once and then benefit from that configuration as part of their normal workflow.

Is there a plan to address constituency codes, campaigns and appeals? These are pretty important criteria for us to be able to exclude.

This item is not shipped by query in WebView. The whole reason we like NXT lists is that it is a lot easier to understand by Fundraisers. Fundraisers should not be required to understand query to be able to use NXT List. NXT list is a simple tool that is easy to use and easily understandable by non admins. However, without being able to filter out information, folks will just export the list and use that to filter out, thus defeating the purpose of NXT List keeping folks in RE and out of shadow spreadsheets. A "Not" filter has infinite purposes including donors not assigned, no giving history, no actions, no specific custom field. Yes, this could be accomplished via query but that should not be required - it should be in NXT List.

I still agree with those who say this is completely insufficient for staff working with lists who do not have access or competencies to manage the queries themselves. A NOT operators are need needed system wide.

Thank you everyone for the feedback and discussion.

We reviewed the original request behind this idea and the primary need was the ability to support exclusion and "NOT" scenarios when building and refining Lists. With the introduction of Query filters in NXT Lists, users can now exclude records that match selected criteria by leveraging Query-based filtering. This delivers the core capability requested in this idea, which is why we have marked it as Shipped.

It's also important to note that this idea was created before web view Query capabilities were available. Since then, the platform has evolved significantly. Query-backed Lists now provide a flexible way to support a broad range of exclusion scenarios without requiring us to introduce a dedicated NOT operator for every filter type.

As a result, we believe the original, overarching request has been addressed. Rather than keeping this idea open indefinitely to represent a growing collection of individual filtering needs, our goal is to focus on specific remaining use cases. If there is a scenario that cannot be accomplished with the current Query-backed filtering experience, please submit a new idea describing that workflow and desired outcome so we can evaluate and prioritize it independently.

Examples of scenarios raised throughout this idea where your needs may still not be met include:

• Excluding specific constituent codes when creating mailing and email lists.

• Identifying opportunities without an assigned solicitor. This one is planned as part of future list enhancement work.

• Excluding gifts associated with a specific event, campaign, fund, or other criteria from broader fundraising results.

Thank you to everyone who voted, provided examples, and helped us better understand how customers use Lists in their day-to-day work.

Love it!

There are some areas like AddressFinder web that will allow you to use constituent lists to determine who is included. We need to be able to build dynamic constituent lists that allow for both and/or and for not one of to fully use those areas.

For the NOT ONE OF example, our current AddressFinder include query for db view is Primary Education class NOT ONE of (the young alum class years) AND Constituent ID NOT ONE of (ids of a small number of constituents) AND Preferred Seasonal Address = No.

For the OR example, we need a gift list where [Campaign = Comprehensive] OR [Campaign Custom Field = CampaignName] to get all of the comprehensive campaign gifts.

Love it!

Love it!

Love it!

Hi Heather, when I first used this Filter by Query option the other day, the NXT list said it was recently refreshed (after changes had been made) and the Query Filter was something to the effect of "This custom field Import ID is blank", but the names showing up did have that Custom Field on it. The query is dynamic, not static. In that case, I clicked on the Query Filter, hit "edit" on the selected query, and opened the results tab, then hit Save and Close on that query, then those names disappeared. This happened in a few instances, as I was setting up several automations that I had been wanting to do but had been limited by the NXT filters in doing, but since then, it seems to be working as expected! If I can duplicate the issue I'll be sure to take some screenshots for future reference.

This solution feels insufficient for fundraisers. For example, I often create complicated queries myself and use them to create a user-friendly list to send to fundraisers. Those users do not have the permissions or knowledge to edit query filters on lists, but they still may want to refine their list in ways that remain impossible.

Love it!

This seems like a good compromise without making lists super complicated for casual users since lists can use queries as their source dynamically now. I am interested to learn if this is sufficient for most users.

Love it!

Love it!

NXT Lists now support NOT scenarios by leveraging Query filters, allowing users to exclude records that match selected criteria.

This enhancement delivers the core capability requested in this idea, so we are marking it as Shipped. If you have a specific use case where the current Query filter support does not meet your needs, please submit a new idea describing that scenario so we can review it independently.

Rebekah - Thanks for the feedback. I don't think I have enough information yet to understand exactly where the issue is occurring.

Can you clarify a few things?

• Are you using a static query or a dynamic query?

• Are you editing the query criteria itself, or are you using the query filters available from the list?

• When you say you have to "re-run" the query, what specific action are you taking?

The expected behavior differs depending on the query type. For example, dynamic queries refresh automatically, while static queries only update when the underlying query is reprocessed. Understanding your workflow will help us determine whether you're experiencing expected behavior or something that isn't working as designed.

This new update, using Query filters in the NXT list, sounds good in theory but you have to re-run the query to get the filters to apply, so it's kind of useless for my purposes. If I have to manually update it anyway what's the point?

I agree that "is blank" & "Do not include" should be a feature.