Overview
Auto-Add Guests to Database lets your organization automatically place the guests on a group reservation into your database, without anyone manually creating a profile for each guest. It is a setting on a Group Reservation Policy. When it is turned on, every qualifying guest on any reservation that uses that policy is ensured to have a profile in your database, either by matching an existing profile by email or by creating a new offline profile. The same guests can also be assigned, at that moment, to a group, profile tags, sites, and opportunities, based on the options you choose.
When enabled on a Group Reservation Policy, it makes sure each guest on a reservation under that policy has a profile in your database. For each qualifying guest, Vome will reuse an existing profile when the guest's email matches one you already have, or create a new offline profile when no match exists. This keeps repeat attendees from being duplicated and saves you from building profiles by hand.
Open or create a Group Reservation Policy, then turn on "Auto add guests to database." Save the policy. From that point on, qualifying guests on new and updated reservations under that policy are added to your database automatically. The setting is off by default, and while it is off no guest is added automatically.
Under the same policy, you can optionally turn on any of these. They are all off or empty by default:
These combine. A guest is assigned to whatever you have selected across these options.
It happens behind the scenes whenever the reservation roster is built or rebuilt: when a guest claims a spot, when a guest accepts an invitation, when guest details are saved, when the party size changes, and when an administrator opens the reservation's details. Guests take no special step and see no separate screen.
Because it also runs when an administrator opens a reservation, guests who were eligible but not yet added (for example, people who claimed a spot before you turned the setting on) get picked up the next time the reservation is viewed.
If the reservation is tied to a group, each auto-added guest also becomes an active member of that group, and the group is reflected on the guest's profile. If the reservation has no linked group, no group membership is added.
Turning the setting on affects reservations going forward. To apply it to reservations already made under the policy, run the retrospective backfill, which is offered right after you enable the setting. The backfill works through every existing reservation under the policy and ensures each qualifying guest is in your database, in the linked group when one is set, and assigned per your policy options.
The backfill runs in the background and may take a few minutes. You will get a notification (mobile push and email) when it finishes. It is safe to run more than once, as guests already in your database are not duplicated. The backfill only runs when "Auto add guests to database" is on, so enable the setting first.
Yes. Separate from the policy, an administrator can bulk add a hand-picked list of guests. Enter each guest with a name and optional email, phone, and age, then optionally choose a group, profile tags, sites, and opportunities (a specific set or all opportunities) to apply, and save.
Each guest is processed on its own. Vome reuses an existing profile when the email matches, or creates a new offline profile, then applies your chosen group, tags, sites, and opportunities. You will see a result for each guest showing whether they were newly created, linked to an existing profile, or failed, along with totals. A failure on one guest does not stop the others. This bulk action does not send any invitations to the guests.
On a reservation's roster, each person (the reservation lead and every guest) carries an indicator showing whether they are in your database, so you can see at a glance which attendees already have a profile.
No. The automatic path, the backfill, and the bulk add all reuse existing profiles by email rather than adding them twice, so they are safe to run repeatedly.