The members-only evening tour needs a different cutoff time than the general admission calendar. The school program should hide price types the public never sees. The holiday light event wants its own confirmation wording. And a setting you change for one of them seems to change all of them.
That last part is the real frustration. Online sales in Altru are configured in layers, and the layers don’t always line up with how you actually think about your offerings: one event, one program, a category of programs, or everything sold on the web. This guide explains how to think about those layers, how to find out where a given option actually lives in your database, and what to do when the setting you need only exists at a broader level than you’d like.
Start by mapping where each option lives
Before changing anything, list the online behaviors you want to control and figure out which level each one belongs to today. In most Altru databases they fall into rough groups:
- Organization-wide web settings. Things that apply to every online transaction, such as general checkout behavior and site-wide text.
- Web form settings. Options attached to a specific web form, which can be useful because you can have more than one form.
- Program settings. Whether a program is offered online, which price types are available through each sales method, capacity, and descriptive content.
- Event (scheduled occurrence) settings. Date, time, capacity, and sometimes availability for a specific occurrence.
The exact list of options at each level depends on your Altru version and how your database was set up, so don’t trust anyone’s memory, including ours. Open a program, an event, and your web form side by side and write down what you can actually set on each. That one-page map saves hours of guessing later.
Test changes in a sandbox, not on live sales
If your organization has an Altru sandbox or test environment, use it. Change one option, then run a test purchase on the web form for two different programs and see whether both changed. When there’s no sandbox, make the change on a low-traffic program first, and do it outside your heaviest sales hours. If you still can’t tell which level a setting belongs to, Blackbaud support can confirm it for your version.
When the setting only exists at a broader level
This is where most of the work happens. You want something different for one event or one category, but Altru only offers the option for all programs, or only per program when you wanted it per category. There’s no single fix, but these workarounds cover most situations.
Split the web forms
If an option lives on the web form, a second form can carry different settings. Organizations often keep one form for general admission and another for special events or member-only sales, then link to each from the right page of the website. The tradeoff is upkeep: every extra form is another thing to check when you change branding, policies, or payment settings.
Use price types and sales methods for audience differences
Many “different options for different people” needs are really pricing needs. If school groups, members, and the public should see different choices, separate price types offered through different sales methods usually handle that more cleanly than trying to customize the online display. Keep your price type names clear, because they often show up on receipts and reports.
Build your categories on the website, not just in Altru
When you want a whole category of programs (say, all summer camps) to behave or look a certain way online, your own website is often the most practical layer. Group those programs on one page, write the category-specific instructions there, and link only to the relevant sales. Altru still handles the transaction; your site handles the framing.
Put event-specific details in the content fields you control
Program descriptions and similar text fields can carry information that would otherwise need a dedicated setting: age requirements, arrival instructions, refund terms for a one-off event. It’s not as tidy as a true per-event option, but visitors read it before they buy.
Create a separate program when the differences are real
If one event keeps needing exceptions to its program’s online rules, it may simply be a different program. Splitting it out gives you program-level control. Check the reporting impact first, since revenue and attendance will now be counted separately, and agree on naming so reports still group sensibly.
Keep a record of what you changed
Layered settings are easy to forget. Six months from now, someone will wonder why one camp has a different cutoff or why a price type vanished from the web. Keep a short shared document listing each customization, the level it’s set at, the reason, and who made the change. Review it before each season opens, alongside a test purchase for every program you’re putting on sale.
Quick answers
Can I set an online option once for a whole category of programs?
It depends on the option. Some settings are per program only, so a category-level change means updating each program. Check your own database, and if you can’t find a category-level control, assume it isn’t there and plan around it.
Why did changing one program affect others?
The option was probably set at the web form or organization level rather than on the program. Use the mapping step above to confirm where it lives before changing it again.
Is it worth asking Blackbaud?
Yes, especially before building workarounds. Support can confirm what your version allows and whether a setting exists that you haven’t found yet.
