Context
When guests register for an event or donors give through Almabase, those records need to be linked to the right constituent in your database. Without that link, you end up with duplicate profiles, gifts attributed to the wrong person, and hours of cleanup work after every event or campaign.
Auto-mapping handles this for you. As records come in, the system checks whether each one matches an existing constituent — and when it finds a clear match, it links them automatically. Records that can't be matched cleanly go to the review queue so you can decide.
The question is how the system decides what counts as a match. A high school reunion attendee might register with the same email she used in 2009. A donor might use his personal Gmail to give, even though your records show his work address. A parent and child might share a phone number on their profiles.
Auto-mapping rules let you pick the matching logic that fits your data. If your records are clean and emails are reliable, the strictest rule keeps things tidy. If alumni emails go stale faster than you can update them, a broader rule catches matches that your old setup would have missed.
How it works
Auto-mapping rules get triggered as soon as a guest registers or a donor gives, and they run against your Almabase constituents. Every incoming guest or gift is checked against the rule you've chosen. When the rule produces exactly one matching constituent, the record is auto-mapped. When the rule produces no match — or multiple possible matches — the record goes to the review queue, where you can pick the right constituent yourself.
You'll find the auto-mapping rule —
For Events: Under Sync configuration and connectors → Scroll down to Guest auto-mapping settings
For Giving: Under Gift Settings → Scroll down to Gift bulk mapping settings
The three rules
Rule 1: Email matches
The strictest rule. A record auto-maps only when its email exactly matches a constituent's email. This is the original Almabase behavior and remains a strong choice when your email data is well-maintained.
The trade-off: when alumni move from a .edu email to a personal address, or when a donor changes jobs, the old email on file won't match what they enter at registration — even though it's clearly the same person. Spouses who share an email may also be linked to each other's records.
Rule 2: Email and first name both match
Records auto-map only when both the email and first name match. This is the safest rule for institutions where spouses commonly share email addresses, since the first-name check prevents Maria's gift from being attributed to her husband Carlos's profile.
Rule 3: First name matches, plus email or phone
The most flexible rule. A record auto-maps when the first name matches and either the email or the phone matches. This is the right choice when alumni emails go stale frequently — if Maria's email on file is out of date but her phone is current, the system can still find her.
Name matching recognizes nicknames
For any rule that uses first name, Almabase treats common nicknames as equivalent — Nikhil and Nick, Robert and Bob and Rob, Elizabeth and Liz and Beth, William and Bill, Kathryn and Kate. So if your records have "Robert Thompson" and the registration says "Bob Thompson," the system treats it as the same first name.
When a nickname drives a match, the bulk mapping queue shows an alias label next to the constituent name. That way, you can verify it's actually the same person — not a coincidence — before confirming.
Unique match required
All three rules require a unique match. If the rule produces two or more candidate constituents, auto-mapping doesn't fire — the record goes to the review queue so an admin can choose. This protects against attributing a record to the wrong person when there's genuine ambiguity.
For example: if you've chosen the "Email matches" rule and a guest registers with family@gmail.com — an address shared by two constituents in your database — the system won't pick one for you. Both candidates will appear in the queue for your review.
What auto-mapping does NOT do
Auto-mapping is intentionally conservative — it only fires against your Almabase constituents, and only when the rule has a unique match. It does not:
Search your external CRM. When a record doesn't auto-map, the bulk mapping queue picks up where auto-mapping stopped. The bulk queue is broader: it searches both Almabase and your connected CRM (such as Raiser's Edge) and shows you recommendations on name, email, and phone — regardless of which rule you've chosen above.
Automatically create new constituents (unless you configure it to). By default, records that don't match anyone go to the review queue for you to decide. But if you'd rather not review every unmatched record, you can change this — see Profile creation defaults below.
Profile creation defaults
When auto-mapping can't find a match on Almabase, the system needs to decide what to do with the record. Profile creation defaults let you configure that decision — whether to create a new profile right away or send the record to the review queue, where the system can also search your connected CRM for a match.
When no constituent matches
This setting applies as soon as auto-mapping finds no match on Almabase — before the system checks your connected CRM.
Send to review queue (default) — The record goes to the bulk mapping queue, where the system searches your connected CRM for a possible match. An admin reviews the results and decides what to do. This is the recommended setting for most institutions.
Automatically create a new profile — A new Almabase constituent is created immediately, without checking your connected CRM first. Records that don't have any contactable information (no email, phone, or address) still go to the review queue.
Why "Send to review queue" is recommended: When auto-create is enabled, the system creates a new Almabase profile before searching your CRM. If that person already exists in Raiser's Edge or BBCRM, you'll end up with a new Almabase profile that isn't linked to their CRM record — and you'll need to manually add the CRM System Record ID to connect them. The review queue avoids this by checking the CRM first, so you can link to the right record without creating duplicates.
Only consider auto-create if your institution doesn't use a connected CRM, or if the vast majority of your unmatched records are genuinely new people who don't exist in any system.
When matched to a CRM constituent
This applies when you've kept the recommended "Send to review queue" setting and the bulk mapping queue finds a match in your connected CRM (such as Raiser's Edge NXT or BBCRM). These records are always flagged for review — the setting controls what action is pre-selected when you review them in bulk.
Map only to CRM profile (default) — Link the record directly to the CRM constituent. No Almabase profile is created. This is faster, but the record won't appear in Almabase-only views.
Create a profile on Almabase and map — Create a new Almabase profile linked to the CRM constituent. The record appears in both systems. You can override this on individual records during mapping.
This setting doesn't skip review — it pre-fills the default action so that when you process records in bulk, the most common choice is already selected. You can still change the action for any individual record before confirming.
Choosing the right rule
A simple way to think about it:
Pick Email matches if your email data is clean and current. You'll get the highest precision, but may have more records to review when emails are out of date.
Pick Email and first name both match if spouse collisions are your biggest worry. You'll catch most of what email-only catches, minus the spouse mix-ups.
Pick First name matches, plus email or phone if your audience has alumni with stale emails. You'll auto-map more records by leaning on the phone signal when the email no longer works.
You can change the rule any time. The change takes effect on the newly created guests or gifts.
Example
Maria Gonzalez graduated in 2014. Her record in Almabase has her university email, mgonzalez14@example.edu, and her phone, +1 (305) 555-0188.
This year, Maria registers for the Reunion Weekend with her current email, maria.g@gmail.com, and the same phone. Here's how each rule handles her:
Email matches → No match. Her registration email isn't in your database. Her record goes to the review queue.
Email and first name both match → No match. Same reason — the email doesn't match.
First name matches, plus email or phone → Match. "Maria" matches her first name, and her phone matches. She's auto-mapped to her existing profile.
Frequently asked questions
What happens to my current setting when the new rules become available?
You stay on Email matches — the rule that matches Almabase's original behavior. Nothing changes about how your sync works until you choose a different rule. You can keep the current rule indefinitely if it's working for you.
Can I change the rule later?
Yes. You can change the rule at any time from Sync configuration and connectors → Guest mapping. The new rule applies to the next sync; previously mapped records aren't re-evaluated.
Does the auto-mapping rule affect gifts and guests records both?
The rule above applies to both. But the rule set up is done separately.
For Events: Under Sync configuration and connectors → Scroll down to Guest auto-mapping settings
For Giving: Under Gift Settings → Scroll down to Gift bulk mapping settings
What if I choose a rule and the system finds two matching constituents?
Auto-mapping requires a unique match. If two or more constituents match the rule, the record is sent to the bulk mapping queue — you'll see all the candidates side by side and can pick the right one.
Will broader rules cause incorrect matches?
The "First name matches, plus email or phone" rule is broader but still requires two signals to align — first name plus a contact method. The system never auto-maps on first name alone. If you're concerned about precision, start with Email and first name both match, and observe the results before choosing the broadest rule.
How does nickname matching work? Can I add to it?
The system recognizes common English nicknames (Nick ↔ Nikhil, Bob ↔ Robert, Liz ↔ Elizabeth, and similar).
What about records that don't match any rule?
They go to the bulk mapping queue, where the system finds recommendations across both Almabase and your connected CRM using name, email, and phone — regardless of which auto-mapping rule you've chosen. You can approve, skip, or create new constituents from the queue.
Are records ever auto-mapped to my external CRM (like Raiser's Edge) automatically?
No. Auto-mapping only fires against Almabase constituents. When a record needs to be linked to a Raiser's Edge constituent, it goes through the bulk mapping queue so you can confirm. From there, your Raiser's Edge mapping defaults decide whether an Almabase profile is also created.
Will old records be remapped if I change the rule?
No. Changing the rule affects future syncs only. Records that have already been mapped (or already sit in the review queue) keep their current status. If you want to revisit older unmapped records under the new rule, you'll need to handle them through the bulk mapping queue.
What does the "alias" label mean in the bulk queue?
It means the system used nickname matching to find the constituent — for example, matching "Bob Thompson" in the registration to "Robert Thompson" in your database. The label is your cue to verify the match before confirming, since alias matches are slightly less certain than exact matches.
What if my data has duplicates and a single email belongs to two constituents?
The record goes to the bulk mapping queue with both candidates surfaced. You can pick the correct one, or use this as a signal to merge the duplicates in your database.
What are profile creation defaults?
Profile creation defaults control what happens to records that don't match any Almabase constituent. You can choose whether unmatched records wait for review or are automatically created as new profiles. You can also configure the default action when a record matches a CRM constituent but not an Almabase one. Find these settings under Sync configuration and connectors → Guest mapping.
Should I enable automatic profile creation?
For most institutions, no. Auto-create fires before the system checks your connected CRM, so it can create a new Almabase profile for someone who already exists in Raiser's Edge or BBCRM. You'd then need to manually link that new profile to the CRM record by adding the System Record ID. The review queue avoids this extra step by checking the CRM first. Only consider auto-create if you don't use a connected CRM or if nearly all your unmatched records are genuinely new people.
Does the CRM match setting skip the review queue?
No. When a record matches a CRM constituent, it's always flagged for review. The setting only controls which action is pre-selected — "Map only to CRM profile" or "Create a profile on Almabase and map." This saves time when you're processing records in bulk, since the most common choice is already filled in. You can override the default on any individual record.