Sometimes you don't want everything to sync between Almabase and Raiser's Edge NXT. Maybe your institution considers RE the source of truth for education records and doesn't want changes from Almabase overwriting them. Maybe affiliations are carefully managed in RE, and you'd rather keep Almabase out of that entirely. Or maybe you're fine with new contact information flowing between systems, but you don't want updates or deletes touching what's already in your CRM.

Almabase gives you granular control over what syncs and how. You can turn off sync for an entire entity type (like education or affiliations), for a specific direction (pull only, push only, or neither), and for specific actions (creates, updates, or deletes) — all independently. This article explains how to find and adjust these settings.

Sync rules are configured at Settings → Database → Sync Rules. This page shows every entity type that can sync between Almabase and RE, with separate settings for each direction:

For each entity type and direction, you can set the behavior for three types of changes independently:

For each of these, you have three options:

Automatically Update — The change is applied to the other system without any admin intervention. This is the fastest option but gives you the least oversight.

Review Before Updating — The change is flagged in the Data Inbox for an admin to review and approve before it's applied. This gives you control over what goes through while still keeping you informed of changes.

Do Not Update — The change is ignored entirely. It is not applied to the other system and does not appear in the Data Inbox. The data in the source system is unaffected — the change simply isn't carried across.

To completely stop an entity type from syncing in one direction, set all three actions (creates, updates, and deletes) to Do Not Update for that direction.

For example, to stop education data from pushing to RE (a common configuration, since most institutions consider RE the source of truth for academic records):

Education changes made in Almabase will now stay in Almabase only. They won't generate Data Inbox items and won't reach RE. Education data can still pull from RE into Almabase if you leave those rules active. The same approach works well for Affiliations — if your team manages those exclusively in RE, turn off push for affiliations to prevent Almabase from overwriting them.

You don't have to turn off all sync for an entity — you can be selective. Here are two common configurations:

Block updates but allow new information to flow. You want new email addresses or phone numbers added in Almabase to reach RE, but you don't want changes to existing records overwriting what's already in your CRM. In this case, set creates to Review Before Updating (or Automatically Update), but set updates to Do Not Update. New contact information still flows through, but existing records in RE stay untouched.

Block deletes across entities. A constituent might remove an address, phone number, email, or affiliation in one system, but you don't want those deletions carrying over to the other. This is especially common for the push direction — you don't want a donor cleaning up their Almabase profile to accidentally remove records from RE. Set deletes to Do Not Update for any entity where you want to protect against this, while leaving creates and updates active.

If you want to stop an entire direction of sync — for example, pulling data from RE but never pushing changes back — you can do this at the entity level. Go to Settings → Database → Sync Rules and for each entity type, set all three actions (or whichever actions you want to block) to Do Not Update under the Almabase to RE direction.

When your integration is first set up, Almabase applies these defaults:

RE to Almabase (pull): Creates, updates, and deletes are set to Automatically Update. This means data flows into Almabase freely whenever changes are made in RE.

Almabase to RE (push): Creates and updates are set to Review Before Updating for most entity types. Deletes are set to Do Not Update. This means changes from Almabase land in the Data Inbox for review before reaching RE — nothing pushes automatically by default.

When a sync rule is set to Do Not Update, the system skips that change completely:

This is different from "Review Before Updating," where the change is captured and held for an admin to decide. With "Do Not Update," the system doesn't even record that a change happened from a sync perspective.

When you change a sync rule, the new setting applies only to future changes. Items already in the Data Inbox are not affected — they stay there for you to review or ignore regardless of the new rule. Similarly, changes that were already applied under the old rule are not reversed.

Can I turn off sync for a single field (like just the phone type) rather than the whole entity?
Sync rules are set at the entity level — for example, all phone number fields share the same sync rules. You can't set different rules for the phone number itself versus the phone type within the same entity. However, field mappings (a separate setting) control which specific fields are included in the sync, and individual fields can be deactivated there.

I changed a sync rule but I still see old items in the Data Inbox. Is that normal?
Yes. Changing a sync rule only affects future changes. Items that were already in the Data Inbox before you changed the rule remain there until you approve or ignore them. They won't be automatically cleared.

What's the difference between "Do Not Update" and just ignoring items in the Data Inbox?
"Do Not Update" prevents items from ever reaching the Data Inbox — the system doesn't even track the change from a sync perspective. Ignoring items in the Data Inbox means the change was detected and captured, but you chose not to apply it. Additionally, when you ignore a specific change in the Data Inbox, the system remembers that decision and won't flag the same change again in the future.

Can I set different rules for different constituents?
No. Sync rules apply globally across all constituents for each entity type and direction. You can't set different rules for specific individuals or groups. However, the system does automatically apply extra protection for registered users (constituents who have signed up through your directory) — their basic information changes from RE to Almabase are always flagged for review regardless of your pull rules.

If I turn off sync entirely for an entity (both directions), does existing data stay in both systems?
Yes. Turning off sync doesn't delete or change any existing data. It simply stops future changes from flowing between the systems. Whatever data was already synced remains in both Almabase and RE as it was at the time you turned off sync.

If I re-enable sync for an entity I previously turned off, will it catch changes I missed?
Not exactly — the system doesn't go back and replay individual changes that happened while sync was off. But it doesn't ignore the current state of your data either. When you re-enable sync, the system compares the current data in Almabase with the current data in RE. If there are differences between the two systems — whether those differences built up over days or months — they'll be detected and processed according to your new rules as soon as the record is updated or the next sync cycle runs. So you won't see a log of every change that happened while sync was off, but any data that's currently out of sync between the two systems will be picked up.

Can data drift apart if I only pull from RE and don't push back?
Yes. Over time, the data in Almabase and RE may diverge — especially for fields that constituents update through the member directory. Almabase will have the constituent's latest self-reported information, while RE may have older data. This is the primary trade-off of a pull-only configuration. Many institutions accept this trade-off and periodically review Almabase data to manually update RE where needed.

If I have set up an entity to "Do Not Update" from Almabase to RE and "Automatically Update" from RE to Almabase, what happens when RE has new information — will it replace the data in Almabase or add the new value?
It depends on the entity type. Entities that support multiple values — like email addresses, education records, and employment — will add the new value from RE alongside whatever already exists in Almabase. Entities that hold a single value will replace the existing Almabase data with what's in RE when the sync runs or when a pull is performed. In either case, since push is set to "Do Not Update," nothing flows back to RE — so any changes constituents or admins make in Almabase stay there without affecting RE.