With two systems tracking the same constituent data, it's inevitable that sometimes a field gets updated in both places before the sync has a chance to carry the change across. Maybe an alumni updates their email through the Almabase directory while an advancement officer updates the same email in Raiser's Edge. Or a phone number gets corrected in RE while an admin edits it in Almabase.

When this happens, Almabase doesn't just pick one value and overwrite the other. Instead, it detects the conflict and sends both changes to the Data Inbox for an admin to review. You get to see what each system has and decide which value should win — or edit the data before approving.

A conflict occurs when there's a pending, unreviewed change going in one direction (say, from Almabase to RE) and a new change comes in going the other direction (from RE to Almabase) for the same constituent and the same type of data.

Here's a concrete example: Priya Patel updates her email through the Almabase alumni directory. Because your push sync rule for emails is set to Review Before Updating, that change lands in the Data Inbox waiting for an admin to approve it before it goes to RE. While it's sitting there, someone in the advancement office updates Priya's email directly in RE. When the sync picks up that RE change, Almabase sees that there's already a pending push change for the same constituent's email going the other direction. That's a conflict.

When Almabase detects a conflict, the new change is always sent to the Data Inbox for manual review, regardless of your sync rules. Even if your sync rule for that entity type is set to Automatically Update, the conflict overrides that setting and puts the change in the Data Inbox instead.

This is a safety measure. If both systems have changed the same data, automatically applying one change could silently overwrite the other. By sending conflicts to the Data Inbox, Almabase ensures an admin reviews the situation before any data is lost.

For each flagged change in the Data Inbox, it comes down to what you want the data to look like in both systems. If you want the flagged value to be applied, choose Approve — the change will be synced to the destination system. If you want nothing to change, choose Ignore — the change is dismissed, and both systems stay as they are.

Normally, if your sync rule for an entity type is set to Automatically Update, changes flow between systems without stopping in the Data Inbox. But there are two situations where auto-sync is overridden, and changes are forced into the Data Inbox:

Conflicting changes — As described above, when there's a pending change in the opposite direction for the same constituent and entity type, new changes always go to the Data Inbox.

Registered user profiles — When a constituent has a linked user account (meaning they've signed up and verified their identity through the Almabase directory), changes to their basic information are always sent to the Data Inbox for review, even if your sync rule is set to auto. This protects verified, self-reported data from being silently overwritten.

When you run a one-time or recurring data pull, the pull is treated as an intentional override — conflict detection is not applied. Pull data is applied directly (or through your sync rules), and it does not trigger the conflict check against pending Data Inbox changes.

This is by design: when you initiate a data pull, you're explicitly asking for RE data to come into Almabase. The system assumes you intend for that data to take precedence.

If there's a pending change in the opposite direction, the auto setting is overridden and the new change goes to the Data Inbox for manual review. This prevents one system's data from silently overwriting the other's without anyone reviewing it. If there's no pending opposite-direction change, the auto setting works normally — the most recent change is applied automatically.

If your sync rule for an entity type is set to Automatically Update but you're still seeing changes for that entity in the Data Inbox, it means there was a conflict. For example, most institutions keep the sync rule from RE NXT / BBCRM to Almabase as "Auto" for most entities. In that case, make it a point to periodically check the Data Inbox for changes in the RE → Almabase direction — if anything is showing up there, it's a conflict awaiting your approval.

Note: Basic Information for Registered Users is always flagged for review in Raiser's Edge to Almabase direction, irrespective of the Sync Rule. In this case, you might see changes in RE to AB direction without a conflict.

No. Approving one change applies it to the destination system, but the opposite-direction change remains in the Data Inbox. After approving one side, the remaining change may no longer reflect a real difference (since the systems are now in sync for that field). You should review the remaining change and either ignore it or approve it as appropriate.

Not on its own. Conflicts are specifically designed to prevent data loss — they force manual review instead of automatically overwriting. Data loss would only happen if an admin approves a change without reviewing the opposite-direction change first. That's why it's good practice to look at both sides of a conflict before approving either one.

When a constituent has registered on the Almabase directory and verified their identity, their profile data is considered self-reported and trustworthy. To prevent synced changes from RE from silently overwriting what the constituent themselves has provided, basic information changes for registered users are always sent to the Data Inbox for an admin to review — even if your sync rule is set to auto.

Both changes are dismissed from the Data Inbox without being applied to either system. The data in each system stays as it currently is — the values may still differ between Almabase and RE, but no sync action is taken. If the data changes again later, a new sync event will generate new changes.

No. Conflicts aren't specifically tracked or labeled as "resolved conflicts" in a separate log.

Conflicts happen most often when the same data is actively maintained in both systems. To minimize them, establish clear ownership for each type of data: decide whether emails are primarily managed in RE or Almabase, whether addresses are updated by constituents through the directory or by staff in RE, and so on. Use sync rules to match — set the "owning" system's direction to auto and the other to review or ignore.

When you pull from RE NXT / BBCRM, RE → Almabase reviews will clear for those constituents (for the entities selected in the pull). Almabase → RE reviews will also clear if the data being flagged for review is replaced by the data being pulled from RE.