A parent buys three camp registrations online for their kids. The confirmation email lands with “Dear Jordan,” the parent’s name, and nothing about which child is enrolled in which session. A donor pays $250 for a gala ticket that includes a $75 dinner and wants an email that shows the deductible portion, and the template has no field for it. Questions about web acknowledgement merge fields usually come from situations like these.
Short version: Altru’s web form acknowledgement emails work from a set of merge fields that Blackbaud supplies for each form type. You can rearrange and restyle the email around them, but as far as we know you can’t define new fields of your own. Here’s how to find what your forms actually support, where the usual gaps are, and what to do when the field you need isn’t on the list.
Find the list your form actually offers
The available fields depend on the kind of web form: a donation form, a membership form, a ticketing or event registration form. Each one exposes merge fields tied to that transaction. Don’t rely on a list from another organization or an old help article. Go to the form, open its acknowledgement email, and look at the merge field picker in the editor. That’s the real list for your version and form type.
Two habits will save you some trouble:
- Send a test with real-looking data. Run a transaction on a test or sandbox form with a multi-item cart, a gift with a tribute, or whatever is unusual about your forms. Some fields render differently, or come out blank, depending on what was bought.
- Write down what you found. Keep a short internal note listing which fields each form supports. The next person who edits the email won’t have to repeat the test.
The gaps people usually hit
Purchaser name vs. participant name
Acknowledgement emails go to the person who completed the checkout, and the name fields refer to that person. When one adult registers children, students, or guests, the participant’s name is often not available as a merge field in the acknowledgement. For camps, classes, and events that’s the information the family wants to see. If your test emails show only the buyer, assume this is a real limit and don’t count on a setting to fix it. Confirm with Blackbaud support if you’re not sure.
Receipt amount vs. transaction total
For tax purposes the total paid and the receipt amount (the deductible portion after benefits) aren’t always the same number. If your form only gives you a total, your acknowledgement can’t state the deductible amount by itself. Don’t hard-code a dollar figure or a percentage into the template to cover the gap. It will be wrong the first time a price or benefit value changes.
Anything custom
Attributes, custom fields on the constituent record, membership level details beyond the basics, a personalized ask based on giving history: if it isn’t in the picker, plan on the web acknowledgement not being able to show it. We aren’t aware of a way to map a query column or smart field into that template; if you think your version allows it, confirm with Blackbaud support or test it in a sandbox before building around it.
Options when the field isn’t there
Pick based on how much the missing information matters and how fast it needs to reach people.
- Rewrite around the gap. Often the cheapest fix. Instead of “Your gift of $X is tax-deductible,” say the receipt will follow, or link to a page that explains how fair market value is handled. Instead of naming each participant, list the session or program purchased, if that field is available, and ask the buyer to check the details.
- Treat the web email as a confirmation and send the official acknowledgement later. Keep the instant email short (“we received your order”). Then send the detailed acknowledgement or tax receipt from Altru’s regular acknowledgement and communications tools, where you work from queries and records and have more data to draw on. The tradeoff is the delay plus whoever runs that process, so build a recurring query for it so nothing gets missed.
- Put the details in the record and let staff handle exceptions. For low-volume cases, like a major gift made online, a staff member can follow up personally. That doesn’t scale, but for a handful of transactions a month it’s often enough.
- Send the email from outside the web form. If the detailed acknowledgement has to go out quickly and include participant names, receipt amounts, or custom data, the email needs to be built from Altru query data rather than the form’s built-in template. That’s the point where a separate email tool earns its place.
Before you change anything
- Check with your finance or development lead about what the tax acknowledgement legally needs to say. Don’t let the template’s limits make that decision.
- If you’re turning the web email into a plain confirmation, make sure the detailed acknowledgement process exists and has an owner before you remove anything.
- Re-test after Altru updates. Merge field behavior on web forms is set by Blackbaud and can change between releases.
Where Social Good fits
When the web form’s built-in fields aren’t enough, Email Designer sends automated, branded acknowledgement, eTicket, and renewal emails from Altru queries, so the content can come from whatever data your queries return instead of a fixed field list, and staff don’t have to do manual exports. Altru stays where the transaction and constituent data live.
Quick answers
Can I add my own merge fields to an Altru web acknowledgement?
Not that we’re aware of. The field list is set by the form type. If you need something specific, ask Blackbaud support to confirm for your version.
Why does my email show the buyer’s name instead of the attendee’s?
Web acknowledgements go to the person who checked out, and the name fields usually refer to that person. Participant details generally have to come from a separate email built on query data.
Is the web acknowledgement good enough as a tax receipt?
That depends on what your form can show and what your finance team requires. If it can’t state the deductible amount correctly, treat it as a confirmation and send the formal receipt separately.
