You want a membership form that asks for a second adult’s name only when someone picks a household level. Or a donation form that shows a “tribute name” field only when the donor checks “in honor of.” Every modern form builder does this with a show/hide rule. In Altru, it’s harder than it sounds, and you should know why before you spend an afternoon looking for a setting.
The short answer
Altru’s web forms are built for collecting transactions that map cleanly onto Altru records: constituent details, membership levels, gift amounts, ticket selections. They give you some control over which fields appear and which are required, but they aren’t a general-purpose form builder. As far as we know, there’s no native way to say “if field A equals X, show field B and make it required.” If you think your version or configuration has something like that, confirm it in a sandbox or ask Blackbaud support before you plan around it.
So the real question becomes: what are you trying to accomplish with the rule? Most conditional logic falls into one of three jobs, and each has a different workaround.
Job 1: Show different fields to different people
This is the classic show/hide rule. The most reliable Altru-native answer is to split one form into several.
- Instead of one membership form with a dropdown that changes what’s asked, build a form per level group (individual levels, household levels, premium levels) and link to each from a simple chooser page on your website.
- Instead of one donation form with an optional tribute section, run a general giving form and a separate tribute gift form.
It’s more forms to maintain, and you’ll need to keep shared content (headers, legal text, confirmation messages) consistent by hand. But each form stays simple, every field on it is relevant, and you aren’t relying on anything fragile.
What about custom script?
Some organizations add their own JavaScript to hide and reveal fields on a form page. It can work, but treat it with care. Field markup can change when Blackbaud updates the product, a hidden required field can block submission with an error the visitor can’t see, and whoever wrote the script may not be around when it breaks. If you go this route, document it, test it after every update, and never hide a field that Altru requires.
Job 2: Require something only in certain cases
Conditional “required” logic is the hardest to fake. Altru’s form settings make a field required or optional for everyone who sees that form. If a field should only be required for some submissions, your options are:
- Split the form so the field is required on the version where it always applies.
- Make it optional and say so clearly in the label, for example “Second adult (household memberships only).”
- Catch the gaps afterward with a query (see Job 3) and follow up with the missing information.
Option 2 sounds weak, but plain labeling solves more of these problems than people expect. Visitors skip fields that don’t apply to them when the label tells them to.
Job 3: Do something with the data after it’s submitted
A lot of what people call “form rules” are really rules about what happens next: flag a record, route a gift to a specific staff member, add someone to a mailing list. That work belongs in Altru after submission, not in the form.
- Queries can find recent web transactions that meet any condition you can describe, such as a gift over a certain amount, a tribute with no acknowledgee address, or a household membership with only one member listed.
- Smart fields and attributes can mark constituents so the right people see them in lists and reports.
- A recurring review of those queries, owned by a named person, turns the “rule” into a routine. Weekly is usually enough; daily if gifts or memberships need fast follow-up.
Before you build any of this, sketch your rules in a simple table: the condition, what should happen, and who’s responsible. You’ll often find that half of them don’t need to live on the form at all.
Things to test before you go live
- Submit each form version on a phone as well as a desktop.
- Try submitting with every optional field blank and confirm the record still lands correctly in Altru.
- Check that confirmation messages and acknowledgment emails make sense for each version.
- If you used custom script, test with it disabled to see what a visitor gets when it fails.
When the form itself is the bottleneck
If you’re splitting forms and writing workarounds mostly because the purchase or giving experience feels clunky, it may be worth looking at the checkout layer rather than the rules. Social Good’s Checkouts replace Altru web forms with a branded, mobile-friendly checkout for tickets, memberships, and donations, and the data writes back to Altru. Altru remains where the records live; only the front end changes.
Quick answers
Can I add “if this, then show that” logic to an Altru web form?
Not natively, as far as we’re aware. Splitting into separate forms is the dependable workaround. Verify against your own environment with Blackbaud support if it matters to your plans.
Is it safe to hide fields with JavaScript?
It can be, if you never hide a required field and you retest after every product update. It’s the least durable option on this list.
Where should post-submission rules live?
In Altru queries and a regular review routine. That keeps the logic visible to staff and doesn’t depend on the form.
