Somewhere, another Altru administrator has already built the lapsed-member query you’re about to spend an afternoon on. Maybe it’s the zoo two states over, or the historic house museum your director met at a conference. The question is how to get their work into your database without retyping it from a screenshot.
The short version: Altru doesn’t give you a public place to swap saved queries between organizations, so sharing a query really means sharing its logic. Done well, that works almost as well as a file transfer, and it holds up better when the other organization’s setup differs from yours.
Why a query doesn’t travel on its own
Each organization’s Altru database is its own hosted environment. A saved query lives inside that environment and points at things that only exist there: your membership program names, your attribute categories, your appeal and fund records, your smart fields, your selections. Even if you could lift the query definition out and drop it into another database, half of its filters would be pointing at values that don’t exist on the other side.
That’s why “send me your query” usually turns into “send me screenshots of your query.” Screenshots are a fine start, but they hide the parts that matter most, like which source view the query was built on and whether a filter uses “is one of” or “is not.”
If you’ve heard that query definitions can be exported and imported between Altru databases, it’s worth asking Blackbaud support directly what’s available for your site. We’d rather not guess. Even where some kind of transfer exists, the cleanup described below still applies.
Share a recipe, not a file
The most portable way to hand a query to another organization is a written recipe that someone can rebuild in ten minutes. Here’s the format that tends to survive the trip:
- Purpose in one sentence. “Members whose membership expired 31 to 90 days ago and who have not renewed or rejoined.” This sentence is what lets the other admin decide whether the query fits their situation at all.
- Source view. Name the view you started from (constituents, memberships, revenue, and so on). Starting from the wrong view is the most common reason a rebuilt query returns different counts.
- Filters, in order, with operators. Write each one out in full, including the operator and whether it’s grouped with AND or OR. Mark which values are specific to your organization, for example “membership program = [your general membership program].”
- Output fields. List them in order, plus any you sort on. If the query feeds a mailing or an export, say so, because column order may matter downstream.
- Dependencies. Note any smart fields, attributes, or selections the query relies on. A query that filters on a smart field won’t work until the other organization creates an equivalent smart field.
- Sanity check. Describe what a reasonable result looks like: “For us this returns a few hundred records a month; if you get thousands, check the date filter.” No need for real numbers from your database, just enough to catch a broken rebuild.
A recipe like this takes a few minutes to write and saves the receiving admin from guessing.
Where to keep a shared library
There’s no single official spot, so groups of Altru organizations tend to improvise. Options that work:
- A shared document or folder among a handful of peer organizations, with one recipe per query and a consistent naming pattern (for example “Membership – Lapsed 31–90 days”).
- Blackbaud’s community forums, where admins regularly post query logic in answer to each other’s questions. Search there before building something from scratch.
- Regional or sector user groups, such as museum or zoo peer networks, where someone can volunteer to keep a running list.
Whatever you pick, add a “last tested” date to each recipe. Queries drift as organizations change programs and fields, and a recipe nobody has rebuilt in two years should be treated as a sketch.
Things to strip out before you share
- Constituent data. Share the definition, never the results. Screenshots of a query’s output can expose names, emails, and giving history.
- Internal codes that reveal strategy. Appeal names or attribute values sometimes say more than you meant to share. Replace them with placeholders.
- Hard-coded dates. Swap fixed dates for relative ones (“in the last 90 days”) where Altru supports it, so the recipe stays useful.
When the real need is sharing results
Sometimes “share a query with another organization” actually means “share what the query returns,” say, a list of reciprocal-program visitors for a partner, or a weekly attendance summary for a funder or consortium. That’s a different problem. Exporting to a spreadsheet and emailing it works, but it’s manual, it goes stale, and it’s easy to send more columns than the partner needs.
For that case, Social Good’s Data Bridge syncs Altru query results to Google Sheets and tools like Mailchimp and ActiveCampaign, so a partner can look at a sheet that stays current instead of waiting for an export. Build the query with only the fields the partner should see, and check your data-sharing agreements before anything leaves your organization.
Quick answers
Can I give another organization access to my saved queries?
Not that we know of in any supported way; queries are scoped to your own database. Confirm with Blackbaud support if you need a definitive answer for your site.
Will a rebuilt query give the same results at another organization?
Only if their data is structured the same way. Program names, attributes, and how staff record transactions all affect counts, which is why the sanity-check line in the recipe matters.
