Events and giving campaigns are wonderful opportunities to refresh the contact details you have for your guests and donors. When someone registers for an event or makes a gift, Almabase can take the information they enter on the form and gently flow it into the right Almabase profile — and from there, into Raiser’s Edge or BBCRM, based on the rules you set up.
This article walks you through how that flow works, what you need to set up, and what happens in different situations.
What this covers
This article is specifically about the built-in contact fields that appear on Almabase’s built-in forms for Events and Giving:
Events — the Registration form and Guest form that come with every event
Giving — the Pre-payment form and Post-payment form that come with every campaign
These built-in forms capture the standard contact details like:
Name
Email
Phone
Address
A quick note on custom forms: The extra forms you build and attach to an event or campaign are a different workflow, and are not covered in this article. We’re only talking about the built-in contact capture on Events (Registration/Guest) and Giving (Pre-payment/Post-payment).
Before you go live: a little setup
A few things make this flow smooth. You can think of it as two layers:
Set up the Event and Giving form connector
Set up the Event and Giving form connector
Where to find these connectors?
Events - Go to Tools > Events > Sync configuration and connectors. Find the section Set up Event Connectors.
Giving - Go to Tools > Giving > Gift Connectors.
Note: Connectors can be set up individually for every event and a giving campaign as well.
Connector field mapping (form → Almabase profile)
This tells Almabase which answer on the form should update which field on the profile — for example, the donor email goes to
Profile’s email address field,
The type is assigned as "Personal."
The Primary flag is set as True
The email address can be used for Login purposes (not applicable if you are subscribed to the Events and Giving module only)
By default, Almabase sets up these mappings already, so you don't have to start from scratch, but you can customise if you need to.
Connector rules (how strict do you want to be?)For each mapped area, you can choose:
Auto — apply updates to the Almabase profile automatically
Review — hold the update for an admin to approve first
Don’t update — ignore it for profile updates
Recommendation: Set up the rule as "Review" initially for the first few Events or Campaigns. Once you are sure and comfortable with how the data moves to the profile, set it to "Auto" or "Don't Update" for selected fields as you wish.
Global vs individual
Global vs individual
You can set these up globally for all events and all campaigns, and you can also customize a specific event or a specific campaign if you need different behavior for just that one.
New events and campaigns inherit from your global defaults at the time they’re created — so if you update your global defaults later, existing events and campaigns stay the way they were unless you update them individually.
Constituent sync rules (Almabase profile → Raiser’s Edge / BBCRM)
Constituent sync rules (Almabase profile → Raiser’s Edge / BBCRM)
These are a separate set of rules that decide how profile updates travel onward to your Raiser’s Edge or BBCRM constituent — automatically, or through another review step like Data Inbox.
How the flow works, step by step
A guest registers for your event, or a donor completes a gift.
Almabase looks to see whether the submission is mapped to an Almabase profile (either automatically via email match or manually by an admin).
It then checks the connector field mappings you’ve set up.
For each mapped field, it applies the connector rule:
Auto — the update flows straight to the Almabase profile.
Review — the update waits for your approval
Don’t update — no change is made to the profile.
If it is set to Review, the update is applied to the Almabase profile only after you approve it.
Once the Almabase profile is updated, your constituent sync rules take over and decide how the change flows to Raiser’s Edge / BBCRM — either automatically, or through another review step.
An important thing to keep in mind: In this flow, contact data first lands on the Almabase profile, and only then moves to Raiser’s Edge / BBCRM. It does not skip Almabase.
Where do the reviews get flagged?
Under the respective dashboards for the Events and Giving Campaigns, you will find a section called "Constituent data" with a button "Review and Approve".
This is where all the information will be flagged for review individually for every data point constituent-wise.
What if I need to reprocess past submissions?
This happens more often than you’d think — maybe you set up your rules a bit later, or changed a rule from “Don’t update” to “Review” or “Auto”, or manually mapped a guest or donor after the fact.
For these cases, Almabase gives you a helpful action:
On the individual event or a giving campaign, under the tab where you set up the connector, you will find a button “Process form data for all guests( or donors) on this event(or campaign).”
Clicking this tells Almabase to re-run the built-in form contact data for that event or campaign through your current mappings and rules. So rather than going back to each registration or gift one by one, you can pick up everything that was captured earlier.
How the pieces fit together
It helps to think of it as two short journeys:
From | To | What controls it |
Form answers | Almabase profile | Connector field mapping + connector rules |
Almabase profile | Raiser’s Edge / BBCRM | Constituent sync rules (and Data Inbox, if used) |
Approvals can happen at either step, depending on how you’ve set things up — once when the profile is being updated, and again when that change is being sent to RE / BBCRM.
A few real-world scenarios
A guest’s submission wasn’t auto-matched to a profile. No contact update can flow into Almabase yet, because there’s no profile to update. Once you map them manually, you can use the Process form data action to pick up their info.
Conflicting information. If the form answer and existing data disagree in a way the system considers a conflict, the update is sent for review rather than auto-applied — even if your rule is set to Auto — so you can make the call.
A donor profile gets created from a completed gift. Almabase can apply the gift’s mapped contact information to that brand-new profile so you don’t start with a blank record.
FAQ
1. When should I set up the connector rules? Ideally, before your event or campaign goes live, so registrations and gifts flow the way you want from day one. At the very least, have your global defaults in place before creating lots of events or pages.
2. What if I forgot to set it up, or changed the rule later from “Don’t update” to “Review” or “Auto”? Your new rules will apply to everything processed from that point onward. For the submissions that came in earlier, use the Process form data action on that event or campaign so Almabase can run them through the current mappings and rules.
3. Can I change the rules while an event or campaign is live? Yes, absolutely. The new rules apply to new processing straight away. For anything that already came in under the older rules, just run Process form data to bring those submissions up to date.
4. What if a guest or donor wasn’t auto-mapped, and I had to map them manually later? Once the mapping is done, their submission can be processed through the connector. You can either wait for the natural flow or click Process form data to be sure it runs. The contact details will then flow to the Almabase profile based on your current rules.
5. If I change the mapping to a different person later, will future updates go to the new person? Yes — going forward, Almabase follows the new mapping. Any items still sitting in review will be refreshed to reflect the new link as well. However, anything that was already approved and applied to the previous person before the change won’t roll back automatically — those will need a small manual cleanup on the old and new records.
6. If the registration or gift is linked to a Raiser’s Edge / BBCRM constituent, does the form data go directly to RE / BBCRM? No. This particular flow always goes through the Almabase profile first. If the submission isn’t linked to an Almabase profile, this contact-data path won’t update the profile — and because it goes profile-first, it also won’t push those form answers directly to RE / BBCRM on its own. Mapping the submission to an Almabase profile is what unlocks the rest of the flow.
7. When I approve the data, does it replace what’s already in Almabase or in Raiser’s Edge / BBCRM? It depends on the field being approved. Email addresses are always appended. Phone, Address, and Name always replace existing data on approval. Whether that change then reaches RE / BBCRM, and how it behaves there, is controlled by your constituent sync rules — not by the connector approval itself.
8. If a guest or admin edits a registration later and updates contact info, how does that info flow to the Almabase profile? When the registration is edited, the updated information is picked up by the same flow:
Connector mappings and rules are applied (Auto / Review / Don’t update).
If a review is needed, the update waits for your approval.
Once the Almabase profile is updated, the constituent sync rules handle the next step to RE / BBCRM.
So edits behave just like a fresh submission — the same rules decide where it goes and what needs approval.