When guests register for an event on Almabase, the host (main registrant) needs to be linked to the correct person in your database before the registration can be fully tracked or synced. This link is called a mapping — it connects the registrant to an existing constituent. Accompanying guests don't need to be mapped — mapping them is optional.

Mapping is what ensures that event registrations are attributed to the right person. Without it, the registration sits unlinked — it won't appear on the constituent's engagement history, it won't sync to your CRM if you use a native integration (Raiser's Edge or BBCRM), and while it will still appear in event exports, it won't be connected to a constituent on the file. Whether you sync data automatically or export it manually, mapping the host is the step that keeps your records accurate and complete.

A handful of unmapped guest records is normal after a busy event — a new attendee the system has never seen, an alumna whose email changed, or accompanying guests who don't need to be mapped at all. This guide walks you through clearing your unmapped queue so every host registration is properly linked.

You don't have to map every guest registration by hand. The system has a built-in auto-mapping capability that automatically links registrations to the right constituent the moment a guest registers. In most cases, auto-mapping handles the majority of your records — only the ones it can't confidently match land in your queue for manual review.

When a guest registers, the system looks for a matching record using the rule you've configured. It checks Almabase first; if no match is found there, it checks your connected CRM. If exactly one record matches the rule, the guest is auto-mapped — you never see it in the queue. If no record matches, or if multiple records match, the system can't decide for you, and the record lands in your unmapped queue.

Choose your matching rule under Sync configuration and connectors → Guest mapping. The available options are:

A broader rule means more registrations auto-map and fewer land in your queue. A stricter rule gives you more control but means more manual review.

Records that auto-mapping couldn't place land in the unmapped queue. To access it, go to your Guest dashboard and click Review and Map.

At the top of the queue, use the filters to narrow down to a specific event. This is helpful after a large event when you want to clear that event's queue while the attendee list is still fresh. Skip this step if you want to clear the entire queue at once.

The queue organizes records into three sections based on how confident the system is that it found the right match:

Work through these sections in order, starting with high-confidence matches. This lets you clear the bulk of your queue quickly and saves your judgment for the records that truly need it.

Select the Ready to Approve section. These are guest registrations where the system found a single strong match — for example, the phone number matched and the name is close, but the email didn't match exactly.

For each record, you can:

You can review records one by one, or select multiple and click Map the selected ones to confirm them in bulk.

When the best match is in your CRM but not on Almabase

The system checks both Almabase and your connected CRM (Raiser's Edge NXT or BBCRM) when looking for matches. Sometimes the best match is a constituent who exists in your CRM but doesn't have an Almabase profile yet — this is common for longtime supporters who were in your database before you started using Almabase.

When this happens, you have two options:

We recommend creating the Almabase profile. Here's why: contact information that donors enter on your event forms — an updated email, a new phone number, a changed address — flows to your CRM through a specific chain:

If you map a guest directly to a CRM record without an Almabase profile in between, the registration itself syncs, but the contact information does not. It stops at the form. Creating the Almabase profile completes the chain so both the registration and the guest's updated details reach your CRM.

You can control this behavior automatically: under Events, go to Sync Configuration and Connectors → Profile Creation Defaults.

The setting "When a CRM match is found but no Almabase match" lets you choose between adding these records to the mapping queue (the default) or having the system auto-create an Almabase profile linked to the CRM record. If you enable auto-creation, the system handles this automatically — the guest gets an Almabase profile, the registration is mapped, and contact information flows through the full pipeline without you needing to act on each one.

Move to the Needs Review section. These are guest registrations where the system found one or more possible matches, but the evidence isn't strong enough to be confident — for example, the name matches but the email differs, or more than one constituent could be the right person.

Review each record individually. The queue shows full details of every probable match, including whether the match was found on Almabase or your connected CRM.

For each record, you can:

If you want to clear multiple records at once, select the ones you want to act on and use the bulk action options.

The New Constituent section contains guest registrations where no match was found on Almabase or your connected CRM. These are likely new people who aren't in your database yet — first-time attendees, community members, or accompanying guests.

For each record, you can:

For bulk actions, you have the option to create records in bulk for everyone in this section. Use the Only create records with contact info toggle to control whether the system creates profiles only for records that have an email, phone, or other contact details. Records without contact information are typically accompanying guests (where contact info is not mandatory on the registration form) or guests added manually by an admin. Creating a profile is most valuable for hosts and main registrants — for accompanying guests without contact details, skipping is usually the better choice.

If you'd rather not manually create profiles for every new guest, you can have the system do it for you. Under Events, go to Sync Configuration and Connectors → Profile Creation Defaults. The setting "When no match is found" lets you choose between adding these records to the mapping queue for review (the default) or having the system auto-create a new Almabase profile for each unmatched donor.

With auto-creation enabled, new donors get an Almabase profile the moment they give, their gift is mapped automatically, and the record never reaches your queue. This is a good option for teams that want to minimize manual queue work — especially after high-volume giving days.

Once your queue is clear, every guest registration is linked to the right constituent. This means:

To verify, return to your Guest dashboard. The Guest matching card should show zero pending.

A few habits keep the queue from piling up:

No. Only the host (main registrant) needs to be mapped for a registration to sync and be tracked. Accompanying guests can remain unmapped without blocking anything — mapping them is optional.

Records that are already mapped are tracked and available for sync or export immediately. You can clear part of your queue and return to the rest later. For guests you don't want tracked or synced at all, use the Ignore option — this removes them from the queue entirely. Ignoring or skipping does not delete the guest from Almabase; it only affects whether the registration is linked and included in sync or exports.

Auto-mapping runs the moment a guest registers automatically, linking clear matches instantly — you never see those records. The mapping queue holds the leftovers: records where there was no match, multiple possible matches, or only a weak signal.

The system surfaces both so you can decide. This usually happens with a parent and child who share details, or with duplicate profiles. Look at surrounding details — class year, address, giving history — to identify the right person. If the two records are actually duplicates of the same person, that's worth cleaning up in your CRM or on Almabase separately.

Skip mapping leaves the guest unmapped — it stays in the queue and can be mapped later. Ignore is a deliberate decision to exclude that guest from sync entirely, and it removes the record from the queue.

When to use Skip: Skip is appropriate for accompanying guests who don't need to be mapped for the registration to sync. Avoid skipping a host or main registrant — skipping them means the registration stays unlinked, so guest tracking won't happen and sync won't go through for that registration.

When to use Ignore: Ignore is the right choice when a guest — whether a host or an accompanying guest — doesn't need to be synced to your CRM and tracking their attendance isn't important. This is common for small events or situations where tracking every attendee in your CRM isn't crucial. Ignoring removes the record from the queue permanently so it doesn't keep appearing.

In both cases, the guest registration itself is unaffected on Almabase — these actions only control whether the registration is linked to a constituent and whether it syncs.

Yes. If you catch it right away, use the Undo option in the confirmation message. If you've already moved on and the record is no longer in the queue, navigate to the individual guest record to reverse the action.

Not necessarily. Accompanying guests don't need to be mapped for the registration to sync — only the host does. Creating a profile makes sense when the accompanying guest has enough contact information to be useful in your database and you want to track their engagement independently — for example, a spouse with a valid email address. For guests where you only have a name and no contact details (common for accompanying guests where contact info isn't mandatory on the form, or guests added by an admin), skipping is the more practical choice.

Mapping applies to a specific registration, not to the person permanently. This is intentional — it lets you handle each event in its own context. If a returning attendee keeps appearing, consider broadening your auto-mapping rule so the system catches them automatically.

No — mapping is what prevents duplicates. It links a registration to an existing constituent rather than creating a second profile. New constituents are created only when you explicitly choose Create for a record with no match.

It depends on how your Event connector is set up. Each connector has rules that control what happens when registration information comes in:

You can configure these rules globally (for all events) or individually per event under Sync configuration and connectors.

After every event is ideal — the attendees are fresh in your mind and the queue stays small. At minimum, a weekly review keeps things from accumulating. The longer registrations sit unmapped, the longer they're missing from constituent records.