When a constituent unsubscribes from emails through Almabase — by clicking the unsubscribe link in an email or updating their preferences in the member directory — you want Raiser's Edge NXT to know about it. If RE doesn't reflect the opt-out, your advancement team might continue sending communications to someone who asked to stop receiving them.
Almabase handles communication preferences at two levels, and each level has its own configuration:
Total email subscription — whether a constituent is opted in or out of all email communication. This is configured in the Mapping tab under Settings → Database.
Category-level unsubscribes — whether a constituent has opted out of a specific email category (like "Alumni Newsletter" or "Event Invitations"). This is configured per email category in your email category settings.
Both levels can sync with RE NXT, but each requires its own setup. This article explains how both levels work, what needs to be configured, and how to keep both systems in sync on communication preferences.
How It Works
Level 1: Total email subscription
Total email subscription determines whether a constituent can receive any email from Almabase at all. When a constituent unsubscribes from all emails (rather than a specific category), their email communication preference is set to "denied" in Almabase — they won't receive any email communications.
To sync this total subscription status with RE NXT, you configure the communication preference mapping in Settings → Database → Mapping. Under Communication Preferences, you choose one of two options:
Option A: Import using solicitation codes — Almabase uses a specific solicit code in RE to determine and update total email permission. When records are pulled from RE, Almabase checks whether this solicit code is present on the constituent's record and sets the email permission accordingly. When a total unsubscription happens in Almabase, the solicit code is updated and synced back to RE based on your sync rules.
Option B: Import using "Requests No Email" — Instead of a solicit code, Almabase uses RE's built-in "Requests No Email" flag (found under the "Mark as..." option on a constituent record in RE). When records are pulled from RE, Almabase checks this flag to determine email permission. Total subscription changes in Almabase update this flag and sync back to RE.
Important: You must choose one of these two options and configure it in the Mapping tab. Without this configuration, total subscription status won't sync between the two systems.
Once this configuration is in place, total subscription and unsubscription changes flow in both directions based on your sync rules. When a constituent unsubscribes from all emails in Almabase, the mapped solicit code or "Requests No Email" flag is updated, and the change is pushed to RE — depending on your sync rule, it will either push automatically or land in the Data Inbox for approval. When the same solicit code or flag is changed in RE, the pull sync brings that update into Almabase.
Level 2: Category-level unsubscribes
Category-level unsubscribes are more granular. Almabase uses email categories to organize communications (like "Alumni Newsletter," "Event Invitations," or "Fundraising Appeals"). Every email sent through Almabase can be assigned to a category. Constituents can unsubscribe from specific categories while staying subscribed to others.
Note: Almabase also supports unsubscriptions at a communication group level, but those unsubscriptions are not synced to RE NXT. Only category-level and total unsubscription actions can be mapped to solicit codes and synced.
To sync category-level preferences with RE NXT, you configure a solicit code for each email category individually. In the email category settings, each category has an option to "Sync communication preferences of email category with RE NXT".
When enabled, you select which RE solicit code to link to that category and choose the action type:
Opt in — The solicit code is added to the constituent's record when they unsubscribe from this category. Use this if your institution uses "Do Not Email" style solicit codes (e.g., adding a "Do Not Email — Newsletter" code means they don't want that type of email).
Opt out — The solicit code is removed from the constituent's record when they unsubscribe. Use this if your institution uses "OK to Email" style solicit codes (e.g., removing an "OK to Email — Newsletter" code means they no longer want that type of email).
When a constituent unsubscribes from a specific category in Almabase (for example, clicking "unsubscribe" in a newsletter email), here's what happens:
The unsubscribe is recorded in Almabase — The constituent is removed from that email category's audience. They'll stop receiving emails in that category from Almabase.
The linked solicit code is updated — Based on the action type configured for that category, the solicit code is either added to or removed from the constituent's profile.
The change flows to RE through the sync — The solicit code change is processed like any other sync change. Depending on your sync rules for solicit codes, it either pushes to RE automatically or lands in the Data Inbox for an admin to approve first.
Important: Category-level syncing only works if you've configured a solicit code for that specific email category. Without this configuration, category unsubscribes stay in Almabase and RE is not informed about preferences at the category level.
What does NOT automatically sync to RE
There are a few types of communication preference data that do not automatically flow back to RE:
Email bounces — When an email sent through Almabase bounces (hard bounce or soft bounce), Almabase updates the constituent's email status locally. However, bounce information is not pushed to RE NXT. If you want to update RE when an email bounces, you'll need to do it manually.
Spam reports — If a recipient marks an Almabase email as spam, Almabase records this locally but does not push it to RE.
How RE opt-outs flow to Almabase
The sync works in both directions. When a solicit code or the "Requests No Email" flag is changed in RE, the change flows to Almabase based on your pull sync rules and updates the constituent's communication preference accordingly — at whichever level the solicit code or flag is mapped to. Resubscriptions work the same way in reverse: when a constituent resubscribes, the mapped solicit code or flag is updated and synced through the same rules.
Self-set preferences are protected. If a constituent has set their own communication preference through the Almabase member directory (for example, they personally opted out via the unsubscribe link), the sync will not overwrite their choice with a different value from RE. The constituent's self-set preference takes priority over admin-set or synced values. This prevents a situation where someone unsubscribes through Almabase but then gets re-subscribed because RE had a different status.
Default sync rules for solicit codes
Solicit codes have specific default sync rules that differ from most other entity types:
Pull (RE NXT → Almabase): Create, update, and delete actions are set to Automatically Update. This means solicit code changes from RE flow into Almabase automatically.
Push (Almabase → RE NXT): Create, update, and delete actions are all set to Review Before Updating. This means opt-out changes from Almabase land in the Data Inbox and need to be approved before they reach RE.
You can change these defaults at Settings → Database → Sync Rules if you want opt-outs to push to RE automatically.
FAQs
If someone unsubscribes from an Almabase email, does RE automatically know about it?
It depends on the level of the unsubscribe and your configuration. For a total unsubscription (unsubscribed from all emails), RE is informed if you've configured the communication preference mapping in the Mapping tab and your sync rules allow the push. For a category-level unsubscribe, RE is informed if you've configured a solicit code for that specific email category and your sync rules allow the push. By default, solicit code pushes require manual approval in the Data Inbox.
Should I use solicit codes or "Requests No Email" for total subscription?
It depends on how your institution manages communication preferences in RE NXT. If your team primarily uses the "Requests No Email" flag on constituent records, choose that option. If your team relies on solicit codes to track email opt-outs, choose the solicit code option. Your Almabase customer success contact can help determine which approach is best for your institution during onboarding.
Can RE overwrite a preference that someone set themselves in Almabase?
No. When a constituent sets their own preference through the Almabase member directory (by unsubscribing or updating their preferences), that choice is marked as "self-set." The sync will not overwrite a self-set preference with a value from RE. This protects the constituent's own decision about their communication preferences.
If I want all opt-outs to push to RE immediately without manual review, what should I change?
Go to Settings → Database → Sync Rules and change the push sync rule for solicit codes from Review Before Updating to Automatically Update for the create and update actions. This means any solicit code change in Almabase (including those triggered by unsubscribes) will push to RE automatically.
Someone resubscribed. Does RE get updated?
Yes, through the same mechanism. When someone resubscribes, the mapped solicit code or flag is updated accordingly — and that change flows to RE NXT through your sync rules.