Picture a members’ preview night. One person registers and adds three guests. You need an email and phone for the person paying, but for the guests you really only need a name for the check-in list and maybe a meal choice. If the form asks every guest for a full address and phone number, people either quit halfway through or type “N/A” into every box, and your constituent data gets worse.
The goal is simple to state: require a lot from the registrant, and only what you actually use from each guest. Getting Altru to do that takes some planning, because the event registration form doesn’t always split the two the way you’d like.
Start with what each field is for
Before changing anything on the form, list every field and write down who uses it after the event. Fields nobody uses shouldn’t be required, and often shouldn’t be on the form at all.
- Registrant (the buyer): name, email, and usually phone and billing address. This is the person you send confirmations to and match to an existing constituent record.
- Guests: name for name badges and the door list. Add a meal or dietary preference for seated dinners, or an age group for family programs. Anything past that needs a reason.
Teams often require guest email “so we can market to them later.” Be honest with yourself about whether that happens. Guest emails collected this way are frequently the registrant’s own address typed again, which creates duplicate constituents rather than new prospects.
How Altru handles registrant and guest fields
Altru event registration web forms let you choose which fields appear and which are required. Where people run into trouble is the guest section. Depending on how your event and its registration options are set up, the guest fields may follow the same rules as the main registrant, or offer fewer settings than you’d expect. We haven’t found a reliable way to give guests their own separate set of required fields on every form type, and Altru’s behavior here can vary with the event configuration.
Required-field choices also tend to be made one form at a time. If you were hoping to set a default once and have every new event registration form inherit it, plan on configuring each form, or copying from a form you already trust, unless you confirm otherwise in your own environment.
Because this varies, don’t assume. Confirm it two ways:
- Build a test event in a sandbox or on an unpublished form. Register one person with two guests, try leaving guest fields blank, and see what the form actually enforces.
- Ask Blackbaud support what your version supports for guest field requirements and form defaults. Get the answer in writing so the next admin doesn’t have to rediscover it.
Workarounds that hold up
Require less, then collect the rest later
If guests can’t have their own rules, lean toward fewer required fields overall. Make name required and everything else optional. For the things you truly need from guests, such as meal choices, send a follow-up email to the registrant a week before the event and ask them to reply with details for their party. It’s an extra step for staff, but it keeps the form short enough that people finish it.
Use registration options instead of free-text fields
Where possible, capture guest information through the registration option itself. A “Guest – vegetarian” option and a “Guest – standard” option give you a meal count without any custom field. This works best for small sets of choices and gets messy past three or four.
Put the instructions on the form
If a guest field must stay required, say why right next to it: “We need each guest’s name for the check-in list.” A short reason cuts down on placeholder answers more than a stricter validation rule does.
Keep a “starter” form
Since you may not get a global default, keep one well-configured event registration form as your reference. When a new event comes up, copy its settings rather than starting from a blank form. Write the standard required-field list in a shared doc so seasonal staff building forms use the same rules.
Clean up after the event
Whatever the form enforces, check the results. Run a query on registrants and guests for the event and look for:
- Guest records that share the registrant’s email address
- Names like “Guest,” “TBD,” or “Plus one”
- New constituents that match existing records under slightly different spellings
Fixing these within a week of the event is much easier than untangling them at year-end. If the same problems show up after every event, that’s a sign a required field is pushing people to invent answers.
Where Social Good fits
Much of this comes down to form design and Altru configuration, and you can get most of the way there with the steps above. If the bigger issue is the Altru web form experience itself, our Checkouts product replaces Altru webforms for tickets, memberships, and donations with a branded, mobile-friendly checkout that writes data back to Altru. If your event is sold as tickets, ask us whether it fits the way you collect details for each party before assuming it solves the guest-field question.
Quick answers
Can I make guest email optional but registrant email required?
That’s the setup most organizations want. Whether a given form lets you split them depends on the event configuration, so test it on an unpublished form before launch.
Is there one setting that applies required fields to all event forms?
Don’t count on it. Plan to set fields per form and keep a reference form to copy from, and check with Blackbaud support if a default would save you significant time.
