Two board members split a table at the gala. A family registers for a members-only camp night, and both parents want to be the contact. A corporate sponsor sends three managers, each bringing their own guests. In every case the real-world party has more than one “host,” and Altru’s registration model expects just one.
This article covers how Altru tends to handle hosts and guests for preregistered programs and special events, why co-hosts are awkward, and the workarounds that hold up in reporting later.
How the host and guest model works
When you register people for a preregistered program or a special event in Altru, the registration is organized around a primary registrant. Guests are attached to that person. The host’s constituent record gets the registration and the payment, and the guests ride along underneath.
That structure works well for the common case: one person buys, one person gets the confirmation, one person is on the hook for the balance. It gets clumsy when two or more people share that role, because Altru doesn’t give you an obvious way to mark a second registrant as an equal co-host on the same registration.
We’re not aware of a native setting that turns on true multi-host registrations, but configurations and releases differ. Before you build a workaround, confirm in a sandbox or test environment, or ask Blackbaud support, whether anything in your version handles it directly.
Decide what “co-host” actually means for you
“Multiple hosts” can mean very different things. Pin down which one you need, because the workaround depends on it:
- Shared credit. Both people should show up as hosts in recognition, attendance history, and stewardship reports.
- Shared payment. Each co-host pays for their own portion or their own guests.
- Shared communication. Both should receive confirmations, reminders, and day-of details.
- Shared seating. The party needs to stay together at a table or in a session, even though separate people booked it.
Most real situations involve two of these, rarely all four. Write down which ones matter before changing anything.
Workarounds that hold up
1. Register each co-host separately and link them
Give each host their own registration, with their own guests underneath. Then tie the registrations together with something you can query: a constituent attribute, a note, or a consistent party name in a field your team already uses. This is usually the cleanest choice when each host pays for their own share, and it gives every host their own attendance history.
The tradeoff: Altru won’t know the registrations belong together. Seating and check-in lists need that link, so make sure the field you choose actually appears on the lists your event staff use.
2. One host, the others as guests, plus a relationship
Keep a single registration with one person as host and the co-host listed as a guest. If the two are already in the same household, or you add a relationship between their constituent records, you can usually reach both through household-aware queries and communications.
This is simplest for couples and families. It’s weaker when you need both people credited equally, since the guest won’t look like a host in most reports.
3. Treat corporate or large parties as a group
When a sponsor or organization sends several people with their own guests, consider whether it’s really a group booking. Recording the organization as the host and the individual attendees as guests often matches how the money moved. It also keeps the invoice in one place.
4. Handle seating outside the registration
If the only reason you want co-hosts is to keep a party together, you may not need to restructure registrations at all. Use a table or group assignment and record the party name consistently so your seating report sorts everyone together.
Keep the workaround reportable
Whichever route you pick, the risk is that co-host details live in someone’s head or a side spreadsheet. A few habits prevent that:
- Pick one field and one format. If you link registrations with an attribute or party name, define the exact format (for example, event code plus the lead host’s last name) and use it every time.
- Build the query before the event. Create a query that lists every registration sharing a party value, with hosts, guests, and payment status. If it doesn’t return what event staff need, fix the approach now.
- Check your confirmations. Confirmation emails go to whoever Altru treats as the registrant. If a second host also needs one, plan to send it from a query or by hand rather than assuming it happens.
- Document it for the next event. Put a short note in your event procedures so the next coordinator doesn’t invent a different method.
Quick answers
Can two constituents both be the registrant on one registration?
Not that we know of in standard configurations. Test in a sandbox or ask Blackbaud support to confirm for your version.
Which workaround is most common?
Separate registrations linked by a shared, queryable value. It keeps payments and attendance history clean for each person.
Do guests get attendance history?
Guests who have their own constituent records can show attendance, but how it appears in recognition and stewardship reports depends on your setup. Run a test registration and check the constituent record before relying on it.
