Skip to content
English
More support Customer portal
Yodelpop Website
  • There are no suggestions because the search field is empty.

RaiserSync FAQs

The following are some common questions that we get, with answers.

 

Q: If the email address is updated in RE, will the HubSpot primary email address get updated?

A: Yes. If you change the main email address for someone in Raiser's Edge, the integration can automatically update the primary email address in HubSpot.

Q: Do all the fields from Raiser’s Edge sync up to the HubSpot fields?

A: No, only the fields that are included in the RaiserSync application, listed above.

Q: Does the installation migrate all historical data from Raiser’s Edge

A: No, there is no historical data migration happening with the installation, or at any point in the standard app.  This can be done with an export / import strategy, ideally early on before donations start syncing over.  A migration through the API can be performed - this would be a separate migration scope.  If that’s desired you can indicate on the RaiserSync Customization Form.

Q: What is the sync timing?

A: 

Standard Version

  • Trigger: Webhooks from Raiser’s Edge NXT

  • Timing:

    • Updates are near real-time as soon as Blackbaud sends a webhook (e.g., new gift, updated constituent).

  • Behavior:

    • Creates or updates contacts and deals in HubSpot only when RENXT sends a new event.

    • If no new gift or constituent update occurs, nothing syncs until the next event arrives.

Enterprise (Plus) Version

  • Trigger: Webhooks from Raiser’s Edge NXT plus scheduled sync for marketing data

  • Timing:

    • Same near real-time behavior as Standard for all new gifts and constituent updates.

    • Adds a scheduled sync every 3 hours for marketing engagement data flowing from HubSpot back into RENXT (e.g., email opens, website activity).

  • Behavior:

    • Updates HubSpot with RENXT data whenever gifts, constituents, or actions change.

    • Updates RENXT with HubSpot marketing data every 3 hours, even if no new gifts exist.

Q: What is the System Record ID and why is it used instead of the Constituent ID

A: In Raiser's Edge NXT, the Constituent ID and the System Record ID serve different purposes:

  1. Constituent ID: This is a unique identifier assigned to each constituent (individual or organization) within the Raiser's Edge NXT database. It serves as a primary key to identify and distinguish between different constituents. The Constituent ID remains constant for a constituent throughout their record's existence in the database. It is often used in reporting, querying, and referencing specific constituents across various functions within Raiser's Edge NXT.
  2. System Record ID: This identifier is also unique but is more broadly used within the system to uniquely identify any record, not just constituents. It applies to all types of records, including constituents, gifts, actions, etc. The System Record ID is crucial for internal system operations, data management, and linking records across different modules or functions within Raiser's Edge NXT.

In summary, while both IDs are unique identifiers within Raiser's Edge NXT, the Constituent ID specifically identifies individual constituents, whereas the System Record ID is a broader identifier used across all records within the system. Each serves a distinct purpose in managing and organizing data within the Raiser's Edge NXT platform.

RENXT-record-sample

Using the System Record ID to match with records in an integration (like syncing Raiser's Edge NXT with HubSpot) is typically preferred over using the Constituent ID for several reasons:

  1. Uniqueness Across All Record Types: The System Record ID is unique for every record in Raiser's Edge NXT, whether it's a constituent, gift, action, or other types of data. This ensures that each record is distinctly identified across all modules. On the other hand, the Constituent ID is specifically tied to constituent records and may not be unique if a constituent has multiple associated records (such as gifts or actions).
  2. Reliability in System-to-System Matching: When integrating Raiser's Edge NXT with another system like HubSpot, you want to ensure you're matching the correct record from Raiser's Edge NXT with its corresponding record in HubSpot. Using the System Record ID allows you to reliably track and map each record without ambiguity, as it's unique to every individual record. If you use the Constituent ID, there could be cases where a single constituent has multiple linked records (e.g., multiple email addresses, gifts, etc.), potentially leading to confusion in matching.
  3. Data Integrity Across Integrations: The System Record ID provides a consistent reference for each data point, especially when the same constituent may be involved in multiple records (e.g., they may have both a donor record and a contact record). By relying on the System Record ID, the integration can ensure the accuracy of data flow between systems, even if the constituent's profile is updated or expanded.
  4. Less Risk of Conflicts: The System Record ID helps to prevent conflicts in scenarios where a constituent record is updated, merged, or has duplicate data. Since the System Record ID is guaranteed to be unique and immutable, it avoids potential issues caused by reusing a Constituent ID across different records or syncing incomplete data.
  5. Future-Proofing for System Changes: If changes or upgrades are made to Raiser's Edge NXT or HubSpot, the System Record ID remains constant, ensuring that integrations can still map records correctly even after system migrations, updates, or restructuring. If you use Constituent IDs, there's a higher risk that changes to constituent relationships or data fields may break the integration.

In summary, using the System Record ID in integrations provides a robust, consistent, and scalable way to match records across systems, ensuring higher accuracy, fewer data mismatches, and better long-term integration stability.

NOTE: The only case to have in mind is that if you update a main email in RS and that email is already associated with another contact in HS (determined through the HubSpot Record ID, so it has a different Record ID), that will generate a conflict and HS won't let you update the contact. You can always use the Duplicates tool to resolve these types of issues.

Q: What email address is being synced as the primary email in HubSpot?

A: RaiserSync pulls the RENXT address flagged as primary—that is, the

Marked Primary Email – Email Address

—and maps it to HubSpot’s Contact Email field. In RENXT, email addresses are stored as a collection, with exactly one entry where

IsPrimary = true

. RaiserSync uses that “Marked Primary Email – Email Address” value when creating or updating a HubSpot contact.

Q: Does RaiserSync import RENXT relationships?

A: RaiserSync only brings in constituents tied to gifts—even if they don’t have an email—because that info is directly needed for donation tracking. Syncing standalone relationships (e.g., “Org A is a Member of Org B”) is more complex: many involve records without emails or explicit opt-in permissions, and we don’t want to create Contacts or Companies in HubSpot without a clear way to email or engage them. As a reminder, HubSpot will still auto-associate a contact to a company if the contact’s email domain matches, but RaiserSync doesn’t pull in any extra relationship data beyond gift connections.

Q: What web and email activity come to RENXT from HubSpot, and where does it go?

A: RaiserSync writes each contact’s latest HubSpot email and website engagement data into RENXT as custom fields on the Constituent record. These fields appear under separate “Field Categories” in RENXT’s Custom Fields setup—one category for email activity (e.g., “Last Email Sent,” “Last Email Open Date”) and another for web activity (e.g., “Last Page Viewed,” “Last Visit Date”). In other words, HubSpot’s most recent email and web metrics land in RENXT’s custom fields, organized by those activity categories so you can see them right on the constituent’s record.

 

RENXT-custom-fields-example

renxt-custom-fields-2

RENXT-custom-fields-3

Q: Where does RaiserSync pick up RENXT communication preferences? Are those the same as solicit codes? How does this affect HubSpot permissions?

A: RaiserSync pulls RENXT’s true opt‐out flags—Do Not Call, Do Not Email, Do Not Mail, and Do Not SMS—directly from each constituent’s Communications/Preferences section via the RENXT API. These flags reflect real permission choices in RENXT and are not the same as solicit codes (e.g., “Newsletter” or “Major Donor”), which are only segmentation labels and do not control opt‐in/opt‐out.

When syncing to HubSpot, each RENXT opt‐out flag is written into its own custom property (rs_do_not_call, rs_do_not_email, rs_do_not_mail). We do not overwrite HubSpot’s built-in communication settings—such as Global Email Opt‐out or individual subscription types—because HubSpot manages its own assets (marketing emails, event invites, workflows, etc.) and may have additional consent details (GDPR records, subscription preferences) that should remain intact. Overwriting HubSpot’s native fields risks removing valid permissions or violating compliance.

It’s important to note that someone who opts out in RENXT (e.g., checking “Do Not Email”) may still want to receive certain HubSpot communications (like your event newsletters or program updates). In other words, a RENXT opt‐out doesn’t automatically apply across all HubSpot assets. To manage this correctly, you’ll need to:

  • Maintain Separate Fields: Keep RENXT opt‐out flags in their custom fields so you can reference them when building HubSpot lists, workflows, and reports.
  • Create a Permission Matrix: Define which types of communications live in RENXT (e.g., appeals, printed newsletters) and which live in HubSpot (e.g., marketing emails, SMS campaigns). This ensures you honor each constituent’s choices in both systems.
  • Plan Your Marcomms Strategy: Decide how RENXT opt‐outs should influence HubSpot campaigns. For example, a donor who “Do Not Email” in RENXT might still receive your HubSpot event invites—but you’d suppress them from RENXT‐originated email appeals.

By syncing RENXT preferences into custom HubSpot fields and maintaining a clear mapping, you can respect donor consent across platforms while still engaging them through the appropriate channels.

 

FAQ: Why Do Old Gifts Suddenly Sync or Update in HubSpot?

RaiserSync listens for real-time updates from Raiser’s Edge NXT. Occasionally, you may see a large number of older gifts or constituent records sync or appear as “updated” in HubSpot. This does not mean new data was imported or added. It simply means many records were changed at once inside RENXT.

Below are the most common reasons this can happen:

1. A Fund, Campaign, Appeal, or Gift Type Was Edited

If any of these shared values are renamed or modified in RENXT, the system automatically updates every gift linked to that value — even gifts from decades ago.
This triggers a burst of “gift updated” events, which RaiserSync processes normally.

2. A Bulk Edit or Global Change Was Run in RENXT

Using RENXT’s Global Change or batch update tools can modify large sets of gifts or constituents.
Examples include:

  • Adding a new field to many gifts

  • Updating attributes or codes

  • Making changes via Query -> Update

Whenever a bulk edit occurs, each affected record will fire a new update event.

3. Constituent Merges or Mass Updates

If constituents are merged, re-assigned, or updated in bulk, connected gifts may also be touched as part of the process, causing related updates to sync into HubSpot.

4. Webhook Backlog or Integration Re-Authorization

If RENXT’s webhooks were temporarily delayed, paused, or disconnected, updates may queue in the background.
When the integration reconnects, RENXT releases the backlog all at once — appearing as an “event flood” in RaiserSync.

5. RENXT System Maintenance

At times, Blackbaud performs background processes that refresh metadata or “last modified” timestamps.
These internal maintenance tasks can cause multiple records to fire update events even without user edits.

What This Means for RaiserSync

  • RaiserSync only syncs data that RENXT marks as newly created or updated.

  • It does not create or modify historic data unless RENXT tells us those records just changed.

  • Seeing old gifts sync usually reflects activity inside RENXT — not an issue inside RaiserSync.

If You See Unexpected Update Activity

If you ever notice a sudden spike in updated gifts or constituents:

  1. Check with your RENXT admins whether any global edits were made.

  2. Look at a sample gift’s “Last Updated” information in RENXT.

  3. Contact us — we can confirm the exact timestamps and help determine the source.