This document describes the known limitations of the iPaaS.com integration with Blackbaud Raiser's Edge NXT. These limitations are inherent to the current integration design and the capabilities exposed by the Blackbaud SKY API. They apply to all subscribers using this integration.

Bulk data import (initialization) is not supported when first connecting Blackbaud Raiser's Edge NXT in iPaaS.com. All data synchronization begins with incremental transfers after mapping collections are configured and transfer methods (webhooks, outbound triggers, or manual sync) are enabled.

What this means for you: Existing records in Raiser's Edge NXT or iPaaS.com are not automatically synchronized when the integration is first installed. You will need to use Manual Sync to transfer existing records individually, or wait for incremental changes to trigger automatic transfers after webhooks and outbound triggers are configured.

This integration supports Constituent and Constituent Address data flows in both directions, and, at the time this documentation was written, one-way Gift creation from iPaaS.com Transactions to Raiser's Edge NXT. Other Blackbaud Raiser's Edge NXT objects — including Campaigns, Funds, Appeals, Events, Memberships, and Opportunities — are not transferred by this integration.

What this means for you: Constituent records (mapped to iPaaS.com Customers) and their child Address records are transferred in either direction. iPaaS.com Transactions whose lines are tagged as gifts are written to Raiser's Edge NXT as Gift records (see the Gift limitations below). If you need to synchronize any other Blackbaud object type, this integration does not support that.

The integration supports Add and Update operations for Constituents in the outbound (iPaaS.com to Raiser's Edge NXT) direction only. Deleting a Customer in iPaaS.com does not delete the corresponding Constituent in Raiser's Edge NXT.

What this means for you: If you need to remove a Constituent from Raiser's Edge NXT, you must do so directly in the Raiser's Edge NXT application. Deleting or deactivating the record in iPaaS.com will not propagate that change to Raiser's Edge NXT.

The integration does not subscribe to the Blackbaud address.add.v1 webhook event. When a new address is created in Raiser's Edge NXT, it does not trigger an immediate standalone address transfer to iPaaS.com. Instead, the new address is picked up the next time a constituent.change.v1 event fires for the parent Constituent. The integration does subscribe to address.change.v1 and address.delete.v1 for standalone address updates and deletions.

What this means for you: After a new address is added to a Constituent in Raiser's Edge NXT, there may be a brief delay before it appears in iPaaS.com. The address will be included the next time any change is made to the parent Constituent record. If you need the address transferred immediately, you can trigger a Manual Sync for the parent Constituent.

Raiser's Edge NXT does not expose custom fields on Constituent Address records through the Blackbaud SKY API. Custom field mappings are supported only on the parent Constituent record, not on child Address records.

What this means for you: If your organization stores custom data on address records in Raiser's Edge NXT (for example, address-level tags or classifications), those values cannot be transferred through this integration. Custom field mappings configured on the address mapping collection will have no effect. Custom fields on the parent Constituent record are fully supported and can be mapped using the eight available data types (Text, Number, Date, Currency, Boolean, Code Table Entry, Constituent ID, and Fuzzy Date).

In the outbound direction (iPaaS.com to Raiser's Edge NXT), addresses are always written as part of a parent Constituent transfer. There is no standalone outbound address-only flow. When a Customer is transferred from iPaaS.com to Raiser's Edge NXT, all associated addresses are included in the same transfer and written after the parent Constituent record.

What this means for you: If you update only an address on an iPaaS.com Customer without changing the parent Customer record, the address change will not be sent to Raiser's Edge NXT unless the parent Customer transfer is also triggered. To ensure address changes are sent, trigger a transfer for the parent Customer record (via outbound trigger subscription or manual sync).

Note: The inbound direction (Raiser's Edge NXT to iPaaS.com) does support standalone address transfers. Address changes in Raiser's Edge NXT are captured by the address.change.v1 and address.delete.v1 webhook events and are transferred independently through the standalone address mapping collection.

When the integration creates a new Constituent in Raiser's Edge NXT, it performs collision handling to detect whether a matching Constituent already exists. If a match is found, the integration links the iPaaS.com Customer to the existing Constituent and updates it instead of creating a duplicate. However, collision handling runs only during outbound Constituent create operations — it does not run on updates or address-only transfers. Address pairing (matching iPaaS.com addresses against existing Raiser's Edge NXT addresses) also runs only during collision handling on create.

What this means for you: After the initial link between an iPaaS.com Customer and a Raiser's Edge NXT Constituent is established, subsequent updates are sent directly to the linked Constituent without re-checking for duplicates. If the link is broken or removed, and the same Customer is transferred again as a new create, collision handling will run again and attempt to find the matching Constituent. Address pairing during collision uses a weighted likeness score — addresses scoring at or above the match threshold are paired with existing addresses, while lower-scoring addresses are created as new records.

When the integration writes a custom field value to a Raiser's Edge NXT Constituent, it first checks whether the referenced custom field category exists. If the category does not exist, the integration attempts to create it automatically via the Blackbaud SKY API. However, some Blackbaud installations restrict category auto-creation through their security configuration. When auto-creation is restricted, the API returns an HTTP 403 error and the custom field write fails.

What this means for you: If you configure custom field mappings that reference a category name that does not yet exist in your Raiser's Edge NXT environment, the integration will attempt to create it. Whether this succeeds depends on your Blackbaud environment's security settings. If auto-creation is blocked, you must create the custom field category manually in Raiser's Edge NXT before transfers using that category will succeed. The error will appear in iPaaS.com under Dashboard / Integration Monitoring / Error Logs. This behavior cannot be fully validated in sandbox environments — confirmation requires a live Blackbaud account with production security settings.

Note: The same auto-creation behavior applies to gift custom-field categories. When you map a value to a gift custom-field category that does not yet exist in your Raiser's Edge NXT environment, the integration attempts to create it; if your environment restricts category creation, create the category manually on the Gift record type in Raiser's Edge NXT before enabling the Gift flow.

This integration requires a Blackbaud Private Application OAuth registration. Public Application registrations are not supported. The subscriber must create a Private Application in the Blackbaud Developer Portal and provide the application credentials (Client ID and Client Secret) during integration setup.

What this means for you: Your organization must have access to the Blackbaud Developer Portal and the ability to create a Private Application registration. The Private Application must be authorized by a Blackbaud environment administrator before the integration can access your Raiser's Edge NXT data. If your organization uses a shared or third-party Public Application for other integrations, that registration cannot be used with this iPaaS.com integration — a separate Private Application is required.

When using both inbound (Raiser's Edge NXT to iPaaS.com) and outbound (iPaaS.com to Raiser's Edge NXT) mapping collections simultaneously, there is a risk of field value loss on the iPaaS.com side. The iPaaS.com API uses PUT (full record replace) when updating Customer records. Fields that are not mapped in the inbound "TO iPaaS.com" mapping collections will be overwritten with empty or null values each time an inbound transfer runs.

The following Customer and Address fields are not mapped in the default template mappings and are at risk of being overwritten:

What this means for you: If your integration stores values in any of the fields listed above on the iPaaS.com side, and you have inbound (TO iPaaS.com) mapping collections enabled, those values will be cleared each time an inbound transfer updates the record unless you take action to preserve them.

Recommended mitigation: Split the TO iPaaS.com mapping collection into separate Add and Update collections, then use the DestinationValue function in the Update collection's mapping formulas to carry forward the existing iPaaS.com value for each field that needs to be preserved. For example, to preserve the existing Customer Number during an update, add a Dynamic Formula mapping with the source formula DestinationValue.CustomerNumber mapped to the iPaaS.com CustomerNumber field. This retrieves the current value from the iPaaS.com record and writes it back, preventing the PUT from overwriting it with null. Repeat for each field that needs to be preserved.

Additional bidirectional considerations:

The inbound (TO iPaaS.com) mapping collections map the Raiser's Edge NXT system record ID — a numeric value (e.g., 280) — directly to the iPaaS.com CustomerNumber field. If another integration also maps its own numeric primary key to CustomerNumber, the values may collide. For example, Raiser's Edge NXT Constituent ID 280 and a different platform's record ID 280 would both write 280 to CustomerNumber on their respective iPaaS.com Customer records, creating an ambiguous identifier.

What this means for you: If your iPaaS.com environment connects multiple integrations that each map a numeric source ID to CustomerNumber, you should ensure that either (a) each integration's ID space does not overlap, or (b) you prefix or transform the CustomerNumber value via a Dynamic Formula mapping (e.g., "RENXT-" + id) to guarantee uniqueness across integrations. The external-ID record managed by iPaaS.com is the primary link between source and destination records and is not affected by this collision — but CustomerNumber is visible to subscribers and may be used in reports, exports, or downstream processes where uniqueness is assumed.

At the time this documentation was written, the Gift flow writes new Gift records to Raiser's Edge NXT only. Changing or removing a gift after it has been created in Raiser's Edge NXT is not sent through the integration, and gifts are written one way — from iPaaS.com to Raiser's Edge NXT — with no inbound gift flow.

What this means for you: Use this flow to record new gifts from your iPaaS.com Transactions in Raiser's Edge NXT. Any later correction to a gift — a changed amount, a reversal, or a deletion — must be made directly in Raiser's Edge NXT. Re-sending a Transaction that has already been transferred does not update the existing gift and does not create a duplicate; instead the transfer stops with a message that updates are not supported for this dataflow, which you can safely disregard for an already-recorded gift. This also means changing a mapping and re-sending will not push the change onto the existing gift.

Subscribers tag each Transaction Line with a routing value (gift, membership, or retail) on a single Transaction-Line custom field. At the time this documentation was written, only lines tagged as Gift are written to Raiser's Edge NXT. Lines tagged for membership or retail (product) purposes are recognized by the routing convention but are not yet written to Raiser's Edge NXT.

What this means for you: A single Transaction can contain gift, membership, and retail lines together; only its gift lines become Raiser's Edge NXT gifts today. Membership and retail lines are safely ignored rather than written incorrectly — a Transaction with only membership or retail lines produces no gift. Each gift is created for its own gift line's amount, so combining gift lines with membership or retail lines in a single transaction does not change the gift amounts — the transaction's overall total, tax, and shipping are not applied to the gift. If your workflow needs membership or retail lines written to Raiser's Edge NXT, submit a feature request through your iPaaS.com partner channel describing the records you need; input like this informs future enhancement releases.

Raiser's Edge NXT records a single payment method on each gift, and the integration writes one gift per gift-tagged Transaction Line for the full line amount. An iPaaS.com Transaction can carry more than one payment, so the integration reduces the transaction's payments to a single payment method for the gift: when the transaction has one payment, that payment's method is used; when it has more than one, the recommended configuration records Other.

What this means for you: When a transaction is paid with more than one method — for example, part credit card and part gift card — the resulting Raiser's Edge NXT gift is a single gift for the full line amount with the payment method recorded as "Other." Specifically:

Choosing a method instead of "Other": The single method is produced by a subscriber-authored formula (the GiftPaymentMethod mapping on the parent Gift collection). The recommended formula returns Other for any multi-payment transaction. If you would rather a specific method "win" on split-tender gifts, change that formula to select one — for example, always use the first payment's method, or apply your own priority rule (the formula can read each payment's method and amount). Whichever you choose, the gift still records one method for the full line amount; the split itself is not represented. If your organization needs split payments itemized on the gift, submit a feature request through your iPaaS.com partner channel describing the requirement.

The Gift flow prevents duplicate gifts using the link iPaaS.com records after each gift is created, rather than searching Raiser's Edge NXT before creating a gift. Once a gift's link is recorded on the source Transaction Line, re-sending that Transaction will not create the gift again. For traceability, the integration also writes the line's reference value onto the gift as a custom field.

What this means for you: Normal retries and re-sends do not create duplicate gifts. The one case where a duplicate can occur is if the source Transaction is wholesale-recreated in iPaaS.com so that its earlier links are lost — a subsequent transfer would then create a second gift. The reference value written on the original gift remains available in Raiser's Edge NXT as a manual reconciliation aid if this occurs.

Note — do not weaken the two mappings duplicate prevention relies on. The link is built from the parent TransactionNumber and the per-line SequenceNumber. Keep TransactionNumber mapped to a genuinely unique per-transaction value, and keep SequenceNumber mapped one-to-one from the source line. Remapping either to a non-unique source can allow duplicate gifts or misrecorded links. iPaaS transaction numbers are unique by default — this note matters only if you change those mappings.

Every Raiser's Edge NXT gift must be recorded against a fund. The Gift flow resolves a fund by its lookup id (the fund identifier shown in Raiser's Edge NXT) at transfer time. If the configured lookup id does not match a fund in your tenant, the fund cannot be resolved and Raiser's Edge NXT rejects the gift.

What this means for you: Before enabling the Gift flow, make sure every fund your gifts reference already exists in your Raiser's Edge NXT tenant, and that the fund lookup id configured in the gift mapping matches it (see Placeholder Values to Replace Before Go-Live). The fund lookup runs once per gift line, so a large transaction that references the same fund on many lines performs a lookup for each.

The default Gift mappings ship with an example value that will not exist on an arbitrary tenant and must be replaced during implementation:

This document covers the seventeen known limitations of this integration plus the pre-go-live placeholder value above. For detailed technical documentation on individual mapping collections, refer to the Blackbaud Raiser's Edge NXT Mapping Collections help center articles.