You ask Altru for “everyone who visited last spring” and get back a list with households, a local foundation, two school groups, and the same member showing up four times. What you wanted was simpler: one row per actual person. Getting that takes a few deliberate choices when you build the query. Each one is easy, but the defaults won’t make them for you.
Below is how we approach constituent-only queries in Altru, and why each choice matters.
Start from the constituent, not the transaction
The source view you pick decides what one row means. Start an ad-hoc query from a revenue, sales, or membership source and each row is a transaction or a membership, so a person who bought tickets six times shows up six times. Start from the Constituents source and each row starts out as one constituent.
You can still filter on activity. From a constituent query you can reach related records (memberships, revenue, attributes, addresses) and use them as criteria. “Constituents who have a membership that expired in the last 90 days” is a constituent question with a membership filter. Phrase it that way when you build it.
Decide which kinds of “constituent” you mean
Altru constituent records cover more than individuals. Organizations, households, and groups are constituents too, and a Constituents-source query returns all of them unless you say otherwise. Before you build, decide which of these you actually need:
- Individuals only. This is the usual choice for email lists, surveys, and member communications. Filter on the field that identifies the constituent as an individual rather than an organization or group. The exact field name can vary by version and configuration, so browse the constituent fields in the query designer and test against records you already know.
- Households instead of individuals. This works best for mailed appeals where you want one piece per address. Pick households on purpose and don’t mix them with individuals, or the same family will get two letters.
- Organizations only. Use this for corporate sponsors, school group contacts, and vendor lists. It’s a separate list with its own filters.
Also decide what to exclude: deceased constituents, inactive records, and anyone flagged with a solicit code or communication preference that rules them out for this purpose. Put those exclusions into the query itself so nobody has to remember them on export day.
Stop one-to-many fields from multiplying rows
This is the usual reason a constituent query returns far more rows than you have people. A constituent can have several email addresses, phone numbers, addresses, memberships, and revenue records. Add any of those as an output field and you get one row for every match, not one per person.
A few ways to keep it to one row:
- Output primary fields only. Use the primary email address and primary address rather than the full related collections. Filtering on “is primary” is the common pattern.
- Filter on related records, but don’t output them. “Has a membership in the Family level” can be a criterion without putting membership columns in the results.
- Use smart fields for summaries. If you need something like total giving or last visit date, a smart field gives you one value per constituent instead of a row per gift. Smart fields are recalculated on a schedule, so check when yours last ran before you trust the numbers.
- Check for a distinct-records option. Some query setups let you return only distinct rows. If you’re not sure whether your version offers this, or how it treats your output fields, test it on a small query and compare the row count to the record count before relying on it.
Save it as a selection
Once the query returns the right people, save a selection from it. A selection is a reusable list of constituent IDs that other parts of Altru can use (communications, exports, other queries) without rebuilding the logic. For lists you reuse every month, such as “active individual members with a valid email,” a dynamic selection stays current as records change.
Name it plainly and put the filters in the description, for example “Individuals, active members, primary email present, excludes deceased and do-not-email.” In six months nobody will remember what “Members List FINAL v2” meant.
Sanity-check before you use it
- Compare the row count to the number of distinct constituent IDs. If they differ, a one-to-many field is still in the output.
- Spot-check five people you know well: a member, a donor, a staff member, someone in a household, and someone who has died.
- Look for names that appear twice with different IDs. That isn’t a query problem. It’s a duplicate record problem, and you fix it in the data, not with filters.
Getting the list where it needs to go
A clean constituent query is often only half the job. The list usually needs to end up in an email platform or a shared spreadsheet, and exporting and re-uploading it by hand every week is where lists go stale. Our Data Bridge syncs Altru query results to Google Sheets, Mailchimp, ActiveCampaign, and other tools, so a well-built constituent query can feed those systems directly instead of going through a manual CSV step.
Quick answers
Why does my constituent query return more rows than constituents?
An output field has more than one value per person, usually email, address, phone, membership, or revenue. Switch to primary fields or move that field from the output to the criteria.
Should I use a query or a selection for a mailing list?
Build the logic in a query, then save a selection from it. Most other Altru processes expect a selection.
