1. Getting Started with Constituent Syncing
Before constituents can sync between systems, you need to:
Establish connection – Connect your Raiser's Edge NXT account to Almabase
Configure field mappings – Select which fields and data you want to sync
Set up sync rules – Define how data flows between the systems
Complete initial pull – Import your existing constituent data from Raiser's Edge
Once this setup is complete, ongoing changes in either system will be managed by your sync rules.
2. The Role of Sync Rules
Sync Rules are the control center for data flow between Almabase and Raiser's Edge. They determine:
What happens when data changes in either system
Whether manual review is done before updates sync over
Which direction does data flow (one-way or bidirectional)
Think of sync rules as traffic signals that control how data moves between systems.
3. Understanding Sync Rules in Detail
3a. Different Rules Available
For each type of data change, you can choose:
Automatically Update – Changes are applied immediately
Review Before Updating – Changes are flagged in Data Inbox
Don't Update – Changes are ignored
3b. Rule Levels: Entity-Based Control
Entities are blocks of information formed by a group of fields that are logically tied together.
For example, Email is an entity formed by all email-related fields tied together - Email address, Email Type, Email preference, etc.
The same goes for address, phone number, and other fields. The Sync Rules are set at the entity level. Here's the list of all default entities
Basic Information
Basic Information
First Name
Middle Name
Last Name
Maiden Name
Nickname/Preferred Name
Prefix (Title - Mr., Ms., Dr., etc.)
Suffix (Jr., Sr., III, etc.)
Gender
Date of Birth
Death Date
Active/Inactive Status
Current City
Marital Information
Marital Information
Marital Status
Email Addresses
Email Addresses
Email Address
Email Type (Personal, Work, etc.)
Primary Email Flag
Phone Numbers
Phone Numbers
Phone Number
Phone Type (Home, Mobile, Work, etc.)
Primary Phone Flag
Addresses
Addresses
Address Line 1
Address Line 2
City
State/Province
Country
County
ZIP/Postal Code
Address Type (Home, Work, etc.)
Primary Address Flag
Education
Education
College/School Name
Course/Degree
Branch/Department
Sub-Department
Division
Campus
Year of Joining
Year of Graduation
Year of Leaving
Class Year
Majors
Minors
Institution ID
Status
Employment/Professional Information/Relationships
Employment/Professional Information/Relationships
Employer Name
Job Title/Designation
Department/Domain
Start Month/Year
End Month/Year
Current Employment Status
Affiliations/Constituent Codes
Affiliations/Constituent Codes
Affiliation Name
Description
Online Presence/URLs
Online Presence/URLs
Website URL
URL Type (Personal, Professional, Social Media, etc.)
Interests/Custom Fields
Interests/Custom Fields
Interest Name
Interest Category
Custom Field Values
Solicit Codes
Solicit Codes
Solicit Code Value
Start Date
End Date
3c. Directional Rule Setting
Rules can be set independently for:
Almabase → Raiser's Edge (Push rules)
Raiser's Edge → Almabase (Pull rules)
Example: Auto-pull from RE, but require review before pushing to RE.
3d. Default Rules
Almabase sets default rules for each entity to ensure the records on Almabase stay up-to-date with the latest information on RE, and at the same time maintain the sanity of the RE data.
The default rules for every entity are —
Almabase → Raiser's Edge: Review Before Updating
Raiser's Edge → Almabase: Automatically Update
This way, nothing gets into RE without your approval, and Almabase data stays up-to-date with the latest RE data.
3e. Example of how sync rule works
Let's take Addresses as an example -
When a new Address is added on Almabase
Don’t Update: Don’t add this new address to the constituent record on Raiser’s Edge OR
Review Before Updating: Flag this new address for review before adding it to the constituent record on Raiser’s Edge OR
Automatically Update: Add this new address to the constituent record on Raiser’s Edge automatically.
When there is an update made to an existing Address on Almabase (assuming the rule is to "Replace")
Don’t Update: Don’t add this updated address to the constituent record on Raiser’s Edge OR
Review Before Updating: Flag this updated address for review before updating it to the constituent record on Raiser’s Edge OR
Automatically Update: Add this updated address to the constituent record on Raiser’s Edge automatically.
When someone deletes the Address on Almabase
Don’t Update: Don’t delete the address on the constituent record on Raiser’s Edge OR
Review Before Updating: Flag this deleted address for review before deleting it from the constituent record on Raiser’s Edge OR
Automatically Update: Delete the address from the constituent record on Raiser’s Edge automatically.
4. Data Inbox – Your Review Center
Purpose
The Data Inbox is where all flagged updates are reviewed before being applied.
What You See
Side-by-side comparison (current vs proposed data)
Source system
Timestamp
Entity type
Actions Available
Approve – Apply change
Ignore/Reject – Keep existing data
5. The Sync Flow Process
Once the constituents are pulled into the system, the sync kicks in immediately based on the Sync Rules. Here's how it works —
Step 1: Change Detection – When any data is updated in Almabase or Raiser's Edge, the system recognizes that an update has been made.
Step 2: Rule Evaluation – The System starts comparing the data between the two systems. It then examines Sync rules to determine the next course of action for every difference in data that is found.
Step 3: Action Execution
Auto Update → Applied immediately
Review Required → Sent to Data Inbox
Don't Update → Ignored
6. Cases Where Standard Sync Rules Don’t Apply
Education Entity updates on RE have to be pulled into AB
Updates made on RE for the Education entity can be brought into AB only through a manual pull.
They do not follow sync rules for RE to AB direction except for when the rule is set as "Don't Update"
Constituent Data Pulls override sync rules
When constituent lists/queries are pulled from RE, the Sync rules are bypassed except for when the rule is set as "Don't Update"
Registered Users
RE to AB for Basic information is always flagged for review for registered users.
If a constituent is registered on the Almabase platform, and any of the fields in Basic Information is updated on RE, then they will always be flagged for review, irrespective of the sync rules.
The reason being a user has claimed their profile on Almabase and might have added information that you may not want to replace without reviewing.
Email, Solicit code, Affiliation — deletion
Delete as a sync rule is only in play for Affiliation, Email address, and Solicit code today.
For other entities, delete isn’t driven the same way from Raiser’s Edge (same underlying reason: no delete notifications for those).
7. Sync behaviour by entity
Sync rules are the same everywhere (what to do on create, update, delete, in each direction). Behaviour still differs among some entities.
A. Phone numbers and addresses
Almabase only supports a fixed set of types. For phones, you work with three types
Mobile
Home
Work
For addresses, you work with two types
Home and
Work
The type mapping between Almabase and Raiser's Edge is set during Implementation.
You can only pull into Almabase what fits those types.
If Raiser’s Edge has more than one phone or address for the same type, Almabase does not keep every duplicate — you get what the integration is built to take (preferred or latest for that type is pulled, depending on the case).
Preferred flag for the phone and address on Raiser’s Edge does not come over — Almabase does not distinguish primary vs non-primary.
B. Education and Other Education
Edits on Raiser’s Edge to Education / Other education do not flow through to Almabase the same way as address or email.
For these edits to make their way to Almabase, the constituent has to be re-pulled. Pull Constituents to Almabase
So, even if your sync rules say “automatic” or “review,” ongoing RE-only education changes will not refresh Almabase until you pull the constituent again
In short, re-pull / refresh is how education updates on RE show up on Almabase.
C. Email, Solicit code, Affiliation — deletion
Delete as a sync rule is only in play for Affiliation, Email address, and Solicit code today.
For other entities, delete isn’t driven the same way from Raiser’s Edge (same underlying reason: no delete notifications for those). <confirm>
D. Affiliation
Affiliations you selected are pulled into Almabase; inactive ones on Raiser’s Edge are not pulled.
Primary flag for the affiliation on Raiser’s Edge does not come over — Almabase does not distinguish primary vs non-primary; all pulled affiliations are treated the same.
Expiry dates on affiliations in Raiser’s Edge are not used when syncing to Almabase.
E. Employment
Only the relationships Employer and Former Employer are pulled as employment. Anything else on RE does not fill the employment block in Almabase.
There are two options to choose from to determine which one is shown as Current Employment —
Based on Employment Type
Based on the End Date of that Employment relationship on Raiser's Edge
F. Email, Phone, and Address
For Email, Phone, and Address fields, “Type” is pulled from Raiser's Edge, but changes to the type are not considered significant updates and are not flagged for review.
Only updates to the core contact information are flagged for review.
Email:
Address
Primary flag
Phone:
Phone number
Address:
Address Line 1
Address Line 2
City
State
Country
Zipcode
What this means:
If the actual contact information changes (e.g., a new email address or updated city), it will be flagged for review.
If only the Type changes (e.g., from Work to Personal), it will not be flagged for review.
Example:
If a constituent changes the email type from Work to Personal, this update will not be flagged for review, since the email address itself has not changed.
8. Other Sync behaviours
A. Append vs Replace (what “Update” really does)
Append and Replace sit on top of your normal sync rules and control how updates are handled for multi-value entities.
Append
Use Append when you want to maintain a history of changes.
If you set Append on an update, every update (new or existing information) is added as a new entry on Raiser's Edge instead of modifying an existing one.
On Raiser's Edge, this may appear as duplicate entries—but this is expected, since each entry represents a point in time.
If the same person updates the same information multiple times, Append will create a new row each time.
Use Append when:
You want to track changes over time (e.g., past addresses, employment history)
Keeping historical records is important
Replace
Use Replace when you want to maintain a single, up-to-date value for each record.
If you set Replace:
New information (e.g., a completely new address) is still added as a new entry on Raiser's Edge
Updates to existing information (e.g., correcting city or updating address line 1) will overwrite the existing entry instead of creating a new one
This ensures you don’t lose genuinely new data, while avoiding duplicates caused by minor edits.
Use Replace when:
You want to keep records clean and up to date without duplicates
You only need the latest version of a specific entry (e.g., current address, phone number)
B. New vs Update vs Delete
Whenever information is added or changed on either Almabase or Raiser’s Edge, the system compares it with existing data on both sides and classifies the change as one of the following:
New – Information that does not exist on the other system
Update – Information that exists but has been modified
Delete – Information that has been removed or replaced
This comparison is done against all existing data on both systems, not just the data that was originally pulled into Almabase.
Example 1: Phone Number
Same number, different “Preferred” setting
Scenario:
Phone number P1 is pulled into Almabase as the Mobile number from Raiser’s Edge.
Raiser’s Edge also has another number P2, but it is not pulled (since only the primary number for a type is pulled).
A user signs up and enters P2 as their mobile number on Almabase.
What happens:
Almabase compares P2 not just with P1 (the pulled number), but with all phone numbers on Raiser’s Edge.
Since P2 already exists on RE, it is not treated as a new number.
The system then compares attributes like the Preferred flag:
If the Preferred setting differs, it is flagged (or synced automatically, based on rules) as an Update to the Preferred field.
At the same time, since P2 replaces P1 on Almabase:
P1 is flagged as a Delete (subject to review rules)
Example 2: Email
Same address, different type
Scenario:
On Almabase, a user adds an email with type T1
On Raiser’s Edge, the same email address already exists with type T2
What happens:
Almabase recognizes that the email address is the same, even though the type is different
This is not treated as a new or unrelated entry
Changes to the Type alone are not considered a meaningful update, and hence:
No review is triggered
No update is flagged
Key takeaway:
The system prioritizes core data (like the actual email, phone number, or address) over metadata (like Type). Matching is always done across all available records, not just previously synced data.
C. Conflicts: Data Inbox + Changes on Raiser’s Edge
What you see
An update (e.g., Address) is already in the Data Inbox, waiting for review (because the rule is set to Review before updating).
At the same time, someone updates the same data on Raiser’s Edge, and that rule is set to Auto-sync to Almabase.
What happens
The system does not automatically apply the RE update in this case.
Before running an auto-sync, it checks if there is already a pending review for that constituent and data type.
If yes:
The RE change is not auto-applied
Both changes are flagged for review
This ensures that:
No updates are silently overwritten
You always have control over which change to keep
You can then:
Approve one and Ignore the other, or
Resolve it based on your internal process
D. Field Not Synced Earlier, but Matches Existing Data on RE
If a field was never pulled from Raiser’s Edge, and a user fills it in on Almabase:
The system still checks against all existing data on RE
If it finds a match:
It links to the existing data
It does not create a duplicate
This is expected behavior when the data matches.
E. Data Marked Inactive on Raiser’s Edge
If data is marked inactive before being pulled, it will not be pulled into Almabase
If data is marked inactive after it has already been pulled:
It remains on Almabase
It is not automatically removed or deleted
Almabase does not remove data just because it is later marked inactive on RE.
F. New Constituent Created
From Raiser’s Edge → Almabase
To bring new constituents into Almabase:
Pull a list or query, OR
Set up a recurring pull
A recurring pull:
Runs at a defined frequency
Only pulls new constituents since the last run
From Almabase → Raiser’s Edge
Control this using Sync Rules:
Review before creating
→ New constituents are flagged for review before being created on REAutomatically create on RE
→ New constituents are created automatically on RE
G. New Field Created in Raiser’s Edge
Does not sync automatically
Requires a mapping configuration update
H. New Value in Code Tables
Becomes available in Almabase on the next pull
Does not update existing records retroactively
I. Updated Code Table Value
Reflected in the next sync/pull
May be flagged for review, depending on sync rules
K. When a Review is Ignored
If a flagged update is not something you want to sync, choose Ignore.
What happens:
Data remains unchanged in the destination system
The update is not synced
The system remembers this decision and will not flag the same change again for that constituent
Example:
A user updates Education from Degree 1 → Degree 2 on Almabase
You decide Degree 1 on RE is correct
You Ignore the review
Result:
Almabase remains Degree 2
RE remains Degree 1
This same change will not be flagged again
L. When a Review is Approved
If you want to keep a flagged update, choose Approve.
What happens:
The data is synced to the destination system
Based on "New", "Update", or "Delete", the data will either get appended, replaced, or deleted on Approve.
M. When a Sync Rule is Changed
Existing items in the Data Inbox are not affected
New rules apply only to future updates
N. When Constituents Are Pulled from Raiser’s Edge
When you run a list or query pull:
Sync rules are overridden, except when the rule is “Don’t Update”
What this means:
Even if fields (like Email, Phone, Address) are set to Review,
a manual pull will still bring all data from RE into AlmabaseThe only exception:
Fields set to “Don’t Update” will still be respected
9. Best practices
Pull constituents at least a day or two before you rely on that data for email or campaigns.
Open Data Inbox on a regular cadence (for example, weekly when you’re notified).
Anything that looks wrong → Support.
10. Frequently Asked Questions
Can I modify field mappings later?
Yes, but this requires configuration updates. Please reach out to the Support team to make these changes so that existing data is not impacted.
What happens when I add a new field in Raiser’s Edge?
New fields do not sync automatically. You will need to update the field mappings for the new field to start syncing.
How are conflicting updates handled?
If the same data is updated on both systems, both changes are flagged for manual review. This ensures no update is applied without your decision.
Can I change default sync rules?
Yes, sync rules can be customized based on:
The data entity (e.g., Email, Address, Education)
The direction of sync (Almabase → RE or RE → Almabase)
Why doesn’t Education updates auto-sync?
To prevent unintended overwrites of curated academic data. Education data is typically maintained carefully on Raiser’s Edge, so updates are flagged for review instead of being auto-applied.
How often do sync cycles run?
Sync runs in near real-time.
Whenever a change is made on either Almabase or Raiser’s Edge, the system processes it almost immediately based on the configured sync rules.
Note: Sync from Almabase → Raiser’s Edge is generally faster than the reverse.
When a review is approved, does it replace existing data?
Only if the review is for "Update" or "Delete", the data gets replaced. If it is New information, it is always appended.
Here's how you can understand what will be New(appended), Update(replaced) or Delete —
I changed sync rules — when do they apply?
New rules apply immediately after saving.
New updates follow the updated rules
Existing items in the Data Inbox remain unchanged until you take action
I added a new custom attribute in Raiser’s Edge. Does Almabase update automatically?
No. You need to:
Rescan the configuration
Select the new field
Pull data again to populate values in Almabase
I added a new value in a Code Table (e.g., Solicit Codes). Will it appear automatically?
No. You need to:
Rescan the configuration
Select the new value under the relevant data type
Pull a record that uses this value so it appears in Almabase
I want to change implementation-level configurations (e.g., affiliations, custom attributes). What should I do?
Please contact the Support team. These configurations are set during implementation and require backend updates.
When I pull data, I see errors. Is the record still created on Almabase?
Yes. The record is still created.
Errors typically relate to specific fields or data points that could not be synced.
Does Almabase pull inactive records or values from Raiser’s Edge?
Inactive data is not pulled from Raiser’s Edge
If data becomes inactive on RE after it was already pulled, it:
Remains on Almabase
Is not automatically removed
Can I modify field mappings later?
Yes, but requires configuration updates. You need to get in touch with our Support team to make any configuration changes. This way, we can ensure none of the existing data is affected.
Can I change default sync rules?
Yes, rules can be customized per entity and direction at any time.
Need Help?
For configuration changes or support, contact your implementation specialist or raise a support ticket.