You open code tables in Altru to add a status like “Verbal yes” or “On hold” for your major gift opportunities, and the opportunity status list isn’t there. Or you find something close, edit it, and nothing changes on the opportunity form. That usually isn’t a permissions problem. The status on a prospect plan opportunity generally doesn’t behave like an editable code table.
Below is what’s going on, how to confirm it in your own database, and the workarounds development teams use to track the stages they actually care about.
Code tables vs. fixed lists
Altru has two kinds of dropdowns. Code tables are lists your administrators own: you can add, rename, and deactivate entries, and the change shows up wherever that field appears. Many constituent, interaction, and revenue fields work this way.
Other dropdowns are fixed system lists. Their values are built into the application because other logic depends on them. Altru’s prospect management comes from the same lineage as Blackbaud’s larger fundraising platform, and in that design the opportunity status is a fixed set of values (things like qualified, response pending, accepted, rejected, and canceled). Those values drive how opportunities are counted and how they relate to the plan, so they aren’t exposed for editing.
I can’t promise the exact list in every Altru release matches that description, so check your own database before you plan around it.
How to confirm it in your database
- Search the code tables list as a user with full administration rights. If there’s no entry tied to opportunity status, that’s a strong sign the field is a fixed list.
- Compare the dropdown values on an opportunity against any code table you suspect is related. If editing the table doesn’t change what the opportunity form shows, they aren’t connected.
- Ask Blackbaud support directly whether the opportunity status values can be modified in your version. A short answer from them saves you from building a workaround around a guess.
Workarounds that hold up
Since you probably can’t change the list itself, the goal is to keep the built-in status meaningful and capture your finer-grained stages somewhere you can control.
1. Map your stages to the built-in values
Write a one-page key: “Our ‘cultivating’ and ‘proposal drafted’ both stay at qualified. ‘Ask made’ moves to response pending. ‘Verbal yes’ stays at response pending until paperwork arrives, then accepted.” This sounds minor, but most status confusion comes from gift officers interpreting the fixed values differently. Agree on the mapping and the built-in field becomes reliable again.
2. Use plan steps for the detail
Prospect plans have steps, and steps carry their own types and statuses, several of which are typically code-table driven. Recording “Proposal sent” or “Site visit scheduled” as a step gives you a dated history of how the prospect moved, which an opportunity status could never show anyway. Check which step fields in your database are editable code tables before you standardize on them.
3. Add a constituent attribute for pipeline stage
If leadership wants a single “where is this donor” value, an attribute is the most flexible option: you define the attribute category and its allowed values, and you can update them later without waiting on anyone. The tradeoff is that an attribute lives on the constituent, not the opportunity, so it gets awkward when one donor has two active asks. Use it for the overall relationship stage, not per-ask tracking.
4. Put the reporting logic in queries
Much of the push to edit status values comes from reporting: someone wants a pipeline report with their own stage names. You can often get there without touching the field. Build an opportunity query that pulls the built-in status, ask amount, expected date, and the most recent plan step, then group or relabel in the export. If you report the same way every month, save the query and keep the relabeling rules alongside it so the next person produces the same numbers.
What to avoid
- Repurposing an unrelated code table to hold opportunity stages. It works for a month, then someone else edits that table for its real purpose.
- Putting stage in the opportunity name or a note. You can’t reliably query free text, and the pipeline report becomes a manual read-through.
- Different conventions per gift officer. If one person marks a verbal pledge as accepted and another leaves it pending, your projected revenue is wrong in both directions. The mapping key from step 1 prevents this.
Quick answers
Can a database administrator unlock the opportunity status list?
Not through the normal administration tools, as far as I know. Full admin rights let you edit code tables, but a fixed system list isn’t a code table. Confirm with Blackbaud support for your version.
Will adding plan steps or attributes affect existing opportunities?
No. They’re separate records. Existing opportunities keep their status, and you can backfill steps or attributes for active prospects as time allows.
Is it worth tracking stages at all in a small shop?
If you have a handful of major gift prospects, the built-in status plus a consistent mapping is usually enough. Add steps or an attribute once more than one person is managing asks and you need a shared picture.
