Your scheduled programs probably share a standard price list: adult, child, senior, member. Then a handful of events break the pattern. A members-only preview at a lower rate, a holiday evening priced higher, a sensory-friendly session with a flat fee. In Altru you can set custom prices on those individual events, and they sell correctly. The trouble starts when someone asks for a list of which events carry custom pricing and what those prices are.
That question is harder to answer than it should be. Below is what to look for in query, why the answer may not be where you expect, and the workarounds that hold up when the field you want isn’t there.
Two different questions that sound the same
Before building anything, be clear about which one you’re asking:
- “What price is configured on this event?” This is setup data. It describes what the event would charge, whether or not anyone has bought a ticket.
- “What did people actually pay for this event?” This is sales data. It lives on orders and revenue, and it reflects what happened at the point of sale, including discounts and comps.
The second question is usually answerable in query. The first is the one that gives administrators trouble, because custom event-level prices are configuration that may not be exposed as a queryable field in your version of Altru.
Check what your query views actually expose
Don’t take anyone’s word for it, including ours. Altru changes over time, and what’s available in query can differ from what you remember. Spend fifteen minutes confirming:
- Start a new ad-hoc query using an event-based source view and expand the related nodes. Look for anything referencing price, price type, or price list.
- Note whether the price fields you find come from the program’s price list or from the event itself. A field that shows the program price will give you the standard rate for every event, including the ones you overrode, which is worse than having no field at all because it looks right.
- Test against a known event. Pick one where you set a custom price, run the query, and compare the output to what you see on the event in Altru. If the numbers don’t match, the field isn’t what you need.
- If you still can’t find it, ask Blackbaud support directly whether custom event prices are available in any query view or report. Get the answer in writing in your case notes so you’re not re-researching it next year.
Workarounds when the configured price isn’t queryable
Use sales data as a proxy
For events that have sold tickets, build an order or sales query that returns event, price type, and unit price paid. Group by event and price type. Events where the paid price differs from your standard list are almost certainly the ones with custom pricing.
The limits are real: this tells you nothing about events with zero sales yet, and discounts or comps can muddy the picture. Filter out discounted lines if your query allows it, or at least flag them so nobody mistakes a promo for a custom price.
Keep a pricing register
The least elegant option is often the most reliable. Keep a simple shared spreadsheet listing every event that gets a custom price, the price types affected, the amounts, and who set them. Make updating it part of the same step as configuring the event. It sounds like busywork, but it’s what finance and front-of-house will actually use, and it doubles as an audit trail when someone asks why last spring’s evening series was priced differently.
Lean on naming or event attributes
If your organization uses consistent event naming or attributes, add a marker for custom-priced events, something like a short tag in the event name or a dedicated attribute value if you have one available. That gives you a field you can filter on in query, even if the price itself isn’t exposed. Pair it with the register above for the amounts.
Reduce how many custom prices you need
Sometimes the cleaner fix is structural. If a recurring set of events always carries the same special pricing, consider whether it belongs in its own scheduled program with its own price list. Then the price is attached to the program, which is easier to report on, and you’re not depending on someone remembering to override each event. Test this in a sandbox first, since moving events between programs affects reporting history and how they appear on your web calendar.
Getting the answer in front of the people who need it
Whatever query you end up with, whether it’s sold prices by event or a list of tagged custom-priced events, the next problem is distribution. Finance wants it monthly, the program manager wants it before every schedule release, and nobody wants to run the query themselves.
Saving the query and exporting it on a schedule works. So does a short checklist that the person who builds events also reviews the pricing register before a season goes on sale.
If you’re already exporting Altru queries into spreadsheets by hand, Data Bridge can sync a saved Altru query to Google Sheets, so a sold-price-by-event query stays current without anyone re-running and re-pasting it. It won’t create a field Altru doesn’t expose, but it does make whichever workaround you choose easier to keep up to date.
Quick answers
Will a program price list field show me custom event prices?
Not reliably. A program-level price field returns the standard rate. Always compare against an event you know has an override before trusting it.
Can I see custom prices for events that haven’t sold anything?
Not through sales data. If you can’t find a configuration-level field in query, a maintained register or an event marker is the practical answer.
