A parent logs in to your website, clicks through to sign their daughter up for a summer camp session, and is handed a blank form asking for their name, email, address, and phone number. The same details they used to create the login five minutes earlier. Some finish it. Some abandon it. A few type their name slightly differently than last year, and now you have two constituent records for one family.
Pre-filling registration forms for patrons who are already signed in sounds like a small thing. In practice it affects completion rates, data quality, and how much cleanup your team does after every registration window opens. Here’s how to think about it in Altru and what you can realistically do.
What “pre-fill” depends on in Altru
For a form to fill itself in, three things have to line up:
- The patron has to be logged in on the same site and session where the form lives.
- The login has to be linked to a constituent record in Altru, not just an account that exists on the website side.
- The specific form has to read from that record when it loads.
The first two are mostly about how your Altru web presence and patron logins are set up. The third is where organizations run into trouble. Different Altru web form types behave differently, and a form that pulls in a logged-in patron’s details in one context may not do so in another, such as program or event registration. We’d rather not guess which combinations work in your version and configuration. The reliable way to find out is to test it.
How to test what your forms actually do
Do this in a sandbox if you have one. If not, use a staff test account on the live site and clean up afterward.
- Create a test constituent with a complete name, email, address, and phone number.
- Register a web login for that test patron through your site (the way a real patron would) and confirm in Altru that it’s linked to the constituent record you just created, not to a new one.
- Log in, then open each registration form you use: camps, classes, lectures, events, members-only programs.
- Note which fields arrive already filled, which are blank, and whether the form still asks the patron to log in again partway through.
- Complete one registration and check whether it posted to the existing constituent or created a new one.
That last check matters more than the pre-fill itself. A form that makes people retype their details is annoying. A form that creates a new record every time is a data problem that grows each season. If the results surprise you, take them to Blackbaud support with the specific form type and your test steps. That gets you a much more useful answer than asking in general terms.
If the form won’t pre-fill, reduce what it asks
When pre-fill isn’t available, the next best fix is a shorter form. Go through each registration form field by field and ask whether you actually use the answer.
- Contact details you already have. For members and returning families, mailing address is often already on the record. If you don’t need it to fulfill the registration, consider dropping it or making it optional.
- Per-participant questions. Allergies, ages, and emergency contacts are often essential for youth programs. Keep these, but put them after the basics so the patron isn’t overwhelmed at the start.
- Marketing questions. “How did you hear about us” and similar fields can usually come off registration forms entirely.
Every field you remove is one fewer thing a returning patron has to retype, and one fewer chance for a mismatched spelling to split a record.
Protect your data when forms don’t recognize people
If your testing shows registrations are creating duplicate constituents, treat it as a standing task rather than an occasional surprise:
- Build a query of constituents added recently (for example, in the past week) and review it during and right after each registration launch, focusing on records that came in from the web.
- Compare those new records against existing ones by email address. Matching emails with different name spellings are the most common pattern.
- Merge duplicates before you send confirmations, rosters, or follow-up communications, so families don’t get two of everything.
- Tell staff which record to keep as the primary when a household has both an old and a new entry, so the decision isn’t made differently each time.
Set expectations on the page
Until the form experience improves, a line of text helps. Something like “Already a member? Log in first, then use the same email address you used before” above the registration link nudges patrons toward the path most likely to attach their registration to the right record. It costs nothing and cuts down on the “I registered twice” emails.
Where Social Good fits
Most of this is testing and form cleanup inside Altru, and none of it requires extra software. If your programs are sold as tickets and you’re looking to replace the Altru web form step altogether, Social Good Checkouts provides a branded, mobile-friendly checkout for tickets, memberships, and donations, with the transaction data written back to Altru.
Quick answers
Does a patron need a web login for pre-fill to work?
Generally yes. Without a login linked to their constituent record, the form has no way to know who they are. Test your specific forms to see what happens once they are logged in.
Why do registrations create new records even for existing patrons?
Usually because the form isn’t matching the patron to an existing constituent, either because they weren’t logged in or because the details they typed didn’t match closely enough. Your test registration will show which.
