You combined a few selections to build a mailing list or a one-off report. Now the job is done, and the information library is full of leftovers: the source selections, the merged result, and maybe a couple of test runs. You try to delete one and Altru refuses, or the delete option simply isn’t there. This is one of the more irritating bits of Altru housekeeping, so here’s how it works and how to clear things out without breaking anything.
Why a selection won’t delete after a merge
When you run a merge selection process, the source selections become inputs to a saved process, and the output is a selection the process created. Altru protects anything another object depends on. As long as the process definition still points at a selection, Altru treats that selection as in use and generally won’t let you remove it.
The same protection applies elsewhere. A selection referenced by an export, a mailing or marketing effort, another query, or a different process will be blocked too. So the merge process may not be the only thing holding a selection in place.
We haven’t confirmed exact behavior across every Altru release and permission setup. If what you see doesn’t match the description here, test the steps on a throwaway selection first, or ask Blackbaud support how your environment handles dependent selections.
A cleanup order that usually works
The general rule is to remove things from the top of the dependency chain down: the process first, then what it produced, then what fed into it.
- Write down what you’re removing. Note the merge process name, its output selection, and each source selection. You want a list to check off, not a guess about which “Spring Appeal FINAL 2” is the real one.
- Check whether the output is still used. If the merged selection fed an export, a mailing, or a report someone runs monthly, stop and ask the owner before going further. Deleting it can break their work quietly.
- Delete or edit the merge process. Open the saved merge selection process and either delete it or remove the selections from it. Until you do, the inputs stay locked. If the process has run history you need to keep for an audit, export or note the results before removing it.
- Delete the output selection. With the process gone, the selection it created should no longer have a dependency and can be removed from the information library.
- Delete the source selections, if you no longer need them. Many source selections come from ad-hoc queries saved only for the merge. Check whether any are used by other processes or queries first. If one still won’t delete, Altru is pointing at another dependency. Find it before you try anything else.
- Delete the underlying ad-hoc queries, if appropriate. A selection is usually tied to the query that generated it. If the query was a one-time build, removing it keeps the library tidy. If it’s reusable, leave it and just delete the extra selection.
When you can’t delete it yourself
Two common blockers have nothing to do with the merge:
- Permissions. Deleting processes, queries, and selections can depend on your security role, and sometimes on who created the item. If the option is missing for you but not for an admin, that’s a role question, not a bug.
- Another user’s work. If a colleague built the process, check with them first. A selection that looks abandoned might be the input for a monthly renewal list.
If you’ve cleared every dependency you can find and the delete is still blocked, open a case with Blackbaud support and include the selection name and the exact error message. They can see dependencies that are hard to spot from the front end.
Keeping the clutter from coming back
Merged selections pile up because they’re quick to make and nobody owns the cleanup. A few habits help:
- Name temporary work clearly. A prefix like “TEMP” plus your initials and a date makes it obvious what can go.
- Use a dedicated folder in the information library for one-time merges, and empty it on a schedule, such as after each mailing or quarterly.
- Delete the process when the job ends. If you’ll never rerun the merge, removing the process right away frees every selection it touched.
- Prefer one well-built query when you can. Sometimes a merge is just a workaround for an OR condition or an exclusion that one ad-hoc query could handle. Fewer moving parts means less to clean up later.
A related problem: duplicates in the merged list
Teams often notice duplicates while combining selections. The same household or person shows up twice because they exist as two constituent records in Altru. Merging selections can’t fix that. The duplicates come from the records themselves. Social Good’s Deduper finds and fixes duplicate constituent and email records in Altru, so the lists you build afterward start from cleaner data.
Quick answers
Does deleting a selection delete the constituents in it?
No. A selection is a list of record IDs. Removing it doesn’t touch the constituent records.
Can I delete the source selections but keep the merged one?
Usually only after nothing points at the sources, and that typically means removing the merge process first. Once the process is gone you can’t rerun the merge. Before you rely on the output selection staying usable afterward, test the sequence on a copy.
