Skip to main content

Almabase Database Setup - Integrating with Raiser's Edge NXT

See how to connect your RE database to Almabase and sync constituents between Almabase and Raiser's Edge NXT

Written by Sarita Markande
Updated today

1. Establish the connection (link RE to Almabase)

Goal: Securely connect your Raiser’s Edge NXT tenant to Almabase so data can be requested on your behalf.

  • Sign in to Almabase Admin. Go to Settings → Database

  • Choose Connect Raiser’s Edge NXT

  • You’ll be sent to Blackbaud to sign in. Use an account authorized to enable this integration for your organization.

  • Select the correct organization and environment (for example, production vs sandbox—pick the one you actually use for live data).

  • Click Authorize.

  • When you return to Almabase, select the newly connected account and run Test Connection.

What “done” looks like: The test succeeds, and Almabase can talk to RE for your chosen account and environment.

2. Configure fields and options (what to bring into Almabase)

Goal: Decide which RE data should appear in Almabase and how it should behave.

  • Your Implementation Specialist will share a supported fields and options guide.

  • You choose which fields and options you need (address types, affiliations, solicit code, etc.—whatever your guide lists).

  • The specialist applies that configuration to your Almabase site so you don’t have to wire fields yourself.

Tip: Spend enough time deciding on the fields and the options you want to bring over. While you can add it later too, editing or removing the fields or options later would need technical assistance.

3. Pull and review a sample (prove the mapping before a big import)

Goal: Confirm that a few real people look correct in Almabase before you scale up.

A) Pull a few individuals (best for testing)

  • Go to the Review tab.

  • Use Select record (or the equivalent control—match your screenshot).

  • Search by constituent name or RE system record ID.

  • Pull completes quickly, so you can spot-check the profile.

Use this path for testing and validation, not as your long-term bulk strategy.

B) Pull many constituents (list or query)

Goal: Bring in a batch from RE using a list or query you already maintain in RE.

Typical flow (labels may be slightly different on your UI):

  1. Go to the Sync Data tab. Choose one-time or recurring (for example, daily/weekly/monthly if your site offers scheduling).

  2. Choose the pull purpose that matches your goal:

    • Profile-style pull — broader record data for your database in Almabase.

    • Email-list-style pull — oriented toward outreach; can create or refresh a communication group for emails (and texts, if your site has that enabled).

  3. Pick the RE list or RE query to drive who is included.

  4. Choose how records should be treated where it’s offered—for example, create new, update existing, or both (wording varies; match the screen).

  5. Select the fields involved and start the pull.

4. Review checklist (for admins)

Purpose: Confirm that what you see in Almabase matches Raiser’s Edge for the constituents and data you chose during setup.

A. Constituent and record status

  • Spot-check a few known constituents side by side with RE.

  • Only active constituents are included in pulls, and only active values for the data types you turned on are brought over — so you should not expect inactive or excluded types to appear.

B. Contact information

  • Compare addresses, emails, and phones to RE.

  • For each contact type you included in configuration, confirm active rows in RE show up as expected in Almabase (inactive or unselected types would not be synced).

  • Emails: Confirm the address you use for mailings is marked Preferred in RE when that matters for your process, and that primary/preferred flags line up after sync.

C. Dropdown and coded fields (values must match configuration)

RE sends lists of allowed values for many fields. After a pull, confirm the options showing in Almabase still line up with what you configured in RE and in Almabase.

Review these especially:

  1. Affiliation

  2. Gender

  3. Solicit codes

  4. Email types

  5. Any other dropdown or coded fields tied to custom attributes you pull from RE

If a value looks wrong, check the code table in RE and your mapping choices before opening a support ticket.

If something is missing, first confirm it is active in RE and included in your field configuration.

Note: If you see additional types or options other than what you selected, it might be because Almabase has some default options. More often than not, they match with your RE options, but in cases where they don't, you can let us know, and we will remove those from the profiles.

D. Pull Master Data

Once the review confirms that all the data looks okay, proceed with pulling the master list following the same steps mentioned here.

5. Sync rules and managing sync (after go-live)

What sync rules are

Sync rules decide how changes move between Almabase and Raiser’s Edge after you are connected—so you are not only doing a one-time import; you are choosing how ongoing updates behave.

Rules apply in two directions:

  • Almabase → Raiser’s Edge (changes made in Almabase that should update RE)

  • Raiser’s Edge → Almabase (changes in RE that should update Almabase)

For each type of data (shown by entity in your Sync Rules screen), you set behavior for three situations:

Situation

Meaning

New information

Something is added that did not exist before on the other side.

Update to existing information

A value that already exists is changed.

Removal of information

Something is removed or end-dated so it should no longer apply.

For each of those situations, and for each direction, you choose one of:

Rule

What it means for admins

Do not update

Do not apply this change through sync (the other system is left as-is for this case).

Review before updating

The change is queued for you to approve or reject before it writes to the other system.

Automatically update

The change is applied without manual approval.

When this kicks in

  • After the database is connected, sync is turned on for your site.

  • Whenever a relevant change happens—either someone updates data in Almabase or data changes in RE (depending on direction and your rules).

  • Not during the very first mapping-only phase before rules matter; it matters once live sync is part of your workflow.

Default rules (typical starting point)

Almabase sets defaults so day-to-day RE updates flow into Almabase, while writes to RE from Almabase stay controlled.

Defaults (each entity/data category):

  1. Almabase → Raiser’s Edge: Review before updating

    • Nothing is written to RE from Almabase without your review, which helps protect the integrity of your RE database.

  2. Raiser’s Edge → Almabase: Automatically update

    • When RE is updated, Almabase stays in step with the latest RE information without you approving every field.

You can change these on a per-entity and per-situation basis as your team’s process evolves; your Implementation Specialist can recommend settings for your policies.

Did this answer your question?