# FundraisingBox Platform Solutions for Implementation Partners #### We Empower Implementation Partners to Deliver Scalable Fundraising & Payment Operation Solutions

Getting started

Everything you need to know about connecting with FundraisingBox.

Cover image
Salesforce NPCSalesforce Nonprofit Cloud (NPC)
Salesforce NPSPSalesforce Nonprofit Success Pack (NPSP)
Microsoft DynamicsMicrosoft Dynamics
As a specialized digital fundraising and payment cloud provider, we enable implementation agencies to deliver nonprofit projects faster, more securely, and with higher quality. Our Platform Solutions extend Salesforce and Microsoft ecosystems into a fully integrated fundraising and CRM environment enhanced by multichannel fundraising, a powerful payment cloud, and advanced CRM capabilities. At the very heart of it all is our API-driven, bidirectional FundraisingBox connector. Our mission is to create the technological foundation for long-term impact and stronger donor relationships. We stand for reducing complexity and empowering partners to build sustainable, scalable solutions that go far beyond traditional system integration.

Become a Partner

Read about the Benefits for Implementation Partners

All-in-One Digital Fundraising ExpertiseCombine Salesforce and Microsoft know-how with proven fundraising, payment and CRM building blocks to deliver comprehensive solutions instead of isolated tools or disconnected implementations.
Fast, Scalable & ReliablePreconfigured architectures and standardized integrations reduce complexity, accelerate delivery, ensure reliable go-lives, and enable efficient, scalable operations with minimal maintenance.
Partner Enablement & Growth SupportAccelerate your business with workshops, co-marketing activities, shared case studies, and practical toolkits. Improve your market access, shorten your sales cycles and deliver stronger project outcomes.
# Salesforce Nonprofit Cloud (NPC)

FundraisingBox Platform Solutions provide the technological foundation for a comprehensive fundraising platform.

Getting startedStep-by-step instructions for setting up the connector.System Setup
Business ProcessesUnderstand the key processes that power daily operations.
Mapping ArchitectureStandardized mappings for reliable data transfer.
By extending Salesforce Nonprofit Cloud with our Platform Solutions including **digital fundraising channels, a payment processing cloud, and centralized data management**, a unified system landscape is created designed for long-term impact and scalable growth. The FundraisingBox Nonprofit Cloud Connector ensures bidirectional real-time synchronization of key data such as contacts and donation records across all payment methods and channels, including SEPA and offline transactions. It is built on the FundraisingBox Nonprofit Cloud App (Managed Package) and follows Salesforce-certified development standards. ### How the integration works The FundraisingBox Nonprofit Cloud Connector ensures a reliable and automated bidirectional data flow with Salesforce Nonprofit Cloud: * Syncronizes donation data with Salesforce in real time * Automatically creates and updates accounts, gift transactions, gift commitments and campaigns * Uses Salesforce Nonprofit Cloud standard objects (like payment schedules and payment instruments) to ensure full compatibility with native features * Extends Salesforce Nonprofit Cloud with additional data structures needed for a comprehensive fundraising platform * Includes built-in validation to reduce mapping errors * Runs continuously in the background after initial setup with built-in error monitoring and automatic notifications
# System Setup # Setup in Salesforce NPC Step-by-step setup guide for the Salesforce Nonprofit Cloud system and the FundraisingBox Nonprofit Cloud Connector ## Required Technical Setup {% hint style="info" %} The final setup is always carried out by the FundraisingBox project team. The required information to establish the interface can be found at the bottom of the page. Please reach out to the FundraisingBox project team to schedule a project. {% endhint %} After successfully acquiring a Salesforce Nonprofit Cloud instance, the standard data model must be extended by installing the **FundraisingBox Nonprofit Cloud Managed Package**, which adds most of the connector-specific data structures. The connector-specific data structure includes: * complete objects with fields, * additional fields within existing Salesforce standard objects, * new values for existing standard fields. More details to be found in [Full Standard Mapping Table](/platform-solutions-integrations/salesforce-nonprofit-cloud-npc/mapping-architecture/full-standard-mapping-table)found under [Mapping Architecture](/platform-solutions-integrations/salesforce-nonprofit-cloud-npc/mapping-architecture). Most of these structural extensions are applied automatically during package installation. However, some configuration steps must be performed manually. These steps are outlined in the chapter "Required Manual Setup Steps" below. *** ### Installation of the FundraisingBox Nonprofit Cloud Managed Package The FundraisingBox Nonprofit Cloud Managed Package must be installed both in the Salesforce test instance and later in the production system. #### **Installation steps** 1. Require the installation link for the FundraisingBox Nonprofit Cloud Managed Package via [Salesforce AppExchange](https://appexchange.salesforce.com/appxListingDetail?listingId=693c15d7-a996-48b6-93ed-fcf0ad5aeb11). The FundraisingBox Team will hand it out afterwards. 2. Log in to the Salesforce instance where the package will be installed. 3. Install the package for all users. 4. Upon completion, the data structure is applied to the Salesforce instance. The package installation will also automatically configure the API connection required for the connector to access the Salesforce instance. {% hint style="warning" %} Existing configurations in Salesforce are neither overwritten nor changed during installation. Only the elements required for the connector are added. {% endhint %} *** ### Required Manual Setup Steps {% stepper %} {% step %} **Configure our Additional Permission Set for Standard Salesforce Objects and Fields** Salesforce users require access to the data structure via permission sets. Two of these permission sets are created automatically during package installation. In addition, one further permission set must be configured manually, since it cannot be included in the package. A prepared set including documentation is available here:[Additional Permission Set for Salesforce Standard Objects & Fields](/additional-resources/additional-permission-set-for-salesforce-standard-objects-and-fields) Before importing the Additional Permission Set, 'PersonAccounts' must be enabled in the Salesforce Setup under *Feature Settings > Sales > Accounts > Person Accounts.* This provides access to Salesforce standard objects and fields required by the FundraisingBox Connector that are not covered by the other permission sets. {% endstep %} {% step %} **Set Up Connector API User and Assign Permission Sets** For the Connector to access to the Salesforce instance, a new API user is required: * Username: e.g., `salesforce@fundraisingbox.com` (can be chosen freely) * Profile: Minimum Access – API Only Integrations * Permission Set License Assignments: * Fundraising Access * Salesforce API Integration **Assign the following permission sets to the Connector API User:** * 'FundraisingBox Connector' Permission Set (provided during package installation) * 'Fundraising Access' Permission Set (provided by Salesforce, required for standard data structure access) * 'FundraisingBox Connector Standard Objects & Fields' Permission Set (configured in step 1) To allow the Connector to create and edit FundraisingBox campaigns as Salesforce campaigns, activate the 'Marketing User' checkbox in the user profile. {% endstep %} {% step %} **Assign Permission Sets to Fundraising Service Users** Users working in Salesforce must also be granted access to the entire data structure and transferred data: * 'FundraisingBox Data User' Permission Set (installed with the package, assign to all service users) * 'Fundraising Access' Permission Set (provided by Salesforce, assign to all service users) {% endstep %} {% step %} **Configure External Client App** The installation package automatically creates an external client app. Assign the Connector API User to this app: 1. Navigate to: *Setup > Apps > External Client Apps > External Client App Manager* 2. Edit policies for the 'FundraisingBox' app 3. Expand *OAuth Policies* 4. Under 'OAuth Flows and External Client App Enhancements', enable '*Client Credentials Flow'* 5. Assign the Connector API User and save {% endstep %} {% step %} **Web Interface Access to Salesforce (optional)** For the FundraisingBox project team, a dedicated support user in Salesforce can be created (preferably with admin rights). * Username: `salesforce+ORGANIZATION@fundraisingbox.com` * Configure the profile so that the password never expires. This support user allows direct access to Salesforce’s web interface for troubleshooting (e.g., issues with data transfer). While not strictly required, it can be useful during the setup phase in the test instance. For production, the API-only user (from step 2) is usually sufficient. {% endstep %} {% step %} **Adjust Existing Data Structure and Layouts** 1. **Add picklist values to the Salesforce standard fields in use** To ensure smooth synchronization with FundraisingBox, some picklists for connector-relevant Salesforce standard fields need to be extended. The affected fields and the values to be added are documented in our [Standard Mapping table](https://docs.google.com/spreadsheets/d/1XiC6p_Fx2sJOX0JYWi2MmafMirlJOPWbsnIP5MrVUVk/edit?gid=795485192#gid=795485192) (highlighted in blue). **The following requirements should be observed:** * The API names of the picklist values for the fields 'GiftTransaction.Status' and 'GiftCommitment.Status' must be in English. Otherwise, internal logic of the Nonprofit Cloud may not function correctly. * For payment methods in the fields 'GiftTransaction.PaymentMethod', 'GiftCommitmentSchedule.PaymentMethod', and 'PaymentInstrument.Type', the API names should also be provided in English whenever possible. Deviating names are technically possible but must be configured separately by the FundraisingBox project team. It is recommended to define the picklist values exactly as described in the Standard Mapping table to ensure error-free processing. 2. **Layout adjustments** To ensure that data transferred via the connector is visible in the user interface, the relevant object layouts must be extended with the FundraisingBox custom fields. The corresponding fields are added, enabled, and positioned in the appropriate section of the user interface within the respective 'Page Layouts' in the Salesforce 'Object Manager'. The affected fields are listed in the [Standard Mapping table](https://docs.google.com/spreadsheets/d/1XiC6p_Fx2sJOX0JYWi2MmafMirlJOPWbsnIP5MrVUVk/edit?gid=795485192#gid=795485192) (highlighted in purple and light green). During installation, the FundraisingBox custom objects are automatically provided with their own layout, in which all fields relevant to the user interface are already enabled. To facilitate access via navigation, the corresponding objects should be added to the navigation bar. * If the payment method '**Wikando Direct Debit'** is used, the corresponding flow button '**Manage Wikando Direct Debit Schedules'** must be enabled in the user interface via the layout of the “Gift Commitment” object. This button allows editing of recurring donations via Wikando direct debit, such as changes to amount, interval, or bank account details. * If **Peer-to-Peer Fundraising Campaign** synchronization is used, a separate section for the FundraisingBox-specific campaign fields should be created in the 'Campaign Layout'. This ensures that these fields are clearly assigned and not confused with fields from other campaign types. 3. **Adjusting Labels of FundraisingBox Custom Fields (optional)** If the labels (displayed field names) of the FundraisingBox custom fields need to be adjusted, this can be done using the 'Translation Workbench Override'. *** {% endstep %} {% step %} **Other Required Settings** * **State and Country/Territory Picklists** must be enabled to ensure that addresses are transferred using country codes instead of country names. * The **'Coordinate Gift Commitment Processing'** flow is currently only available in Salesforce as an inactive template by default. To use it, a separate version must be created and activated. If this is not done, no subsequent transactions can be generated despite the setting being enabled, and the gift commitment will not be updated for new schedules. As a result, the new data will not be processed by the connector. * **Duplicate Management:** For new data submitted via a FundraisingBox form, the first duplicate check is performed within FundraisingBox. A second check takes place in Salesforce. The Salesforce Connector follows the duplicate rules defined in Salesforce (either standard rules or custom rules). These rules can be adjusted in Salesforce if needed. * **Validation Rules:** If validation rules exist in Salesforce such as for required fields or format validations for email addresses these should also be reflected in the configuration of the FundraisingBox forms. This helps prevent errors when the connector creates records. {% endstep %} {% endstepper %} *** ### Required Data for Connector Setup After all setup steps have been completed, the following information must be provided to the FundraisingBox project team to establish the interface between FundraisingBox and Salesforce: * URL of the Salesforce instance * Org. ID of the Salesforce instance * ID of the Connector API User The technical integration can only proceed once this information has been received. # Setup in FundraisingBox ### **Setup of the Connector User in FundraisingBox** In the to be connected FundraisingBox, an additional regular “connector user” must be created. This user can be named “Salesforce Connector REST API” and assigned a generic internal email address. The user permissions can be assigned as follows:
Permissions Customer User FundraisingBox
**The project team requires** * The FundraisingBox User ID (this can be obtained from the User Profil URL) # Business Processes # Manage Account Information ### **Account Data Changes** Changes to account information (e.g., name or address) must be made directly in Salesforce. The connector automatically detects these updates and synchronizes them back to FundraisingBox to ensure data consistency. {% hint style="info" %} Changes only apply to accounts created by the FundraisingBox connector, and only the data relevant for the connector is synchronized back after being updated in Salesforce. The exact fields are listed in the [Standard Mapping table.](/platform-solutions-integrations/salesforce-nonprofit-cloud-npc/mapping-architecture/full-standard-mapping-table) {% endhint %} ### Existing donor makes a new donation with updated information When a known donor makes a new donation through the FundraisingBox form using a new address, email address, or phone number, the account information is automatically updated in Salesforce. * Any new address, email, or phone number entered via the FundraisingBox form is stored as the primary address, email, or phone number. * The previous address, email, or phone number is moved to the 'secondary' address, email, or phone number fields. For more details check the [Standard Mapping table.](/platform-solutions-integrations/salesforce-nonprofit-cloud-npc/mapping-architecture/full-standard-mapping-table) ### Merge Accounts If contacts are merged manually, the merge process must be carried out in Salesforce. The connector detects the merge and applies it accordingly, even if one of the merged contact objects was previously unknown to the connector. To understand how automatic merging by the connector works, please refer to [Duplicate Management.](/knowledge-base/duplicate-management) ### **Delete an Account** If an account created by the Connector is deleted in Salesforce, the Connector will also remove the corresponding contact in FundraisingBox. {% hint style="danger" %} Once deleted, it **cannot be restored**. {% endhint %} # Manage Recurring Donations Recurring donations can be edited, added, or deleted in Salesforce for example, by setting an end date or adjusting the donation amount. The connector detects these changes and transmits them to the payment provider so that the recurring donation is updated accordingly. {% hint style="warning" %} Recurring donations created manually in Salesforce are not synchronized back to FundraisingBox. An exception applies to direct debit donations processed via 'Wikando Direct Debit'. See also: [Initiate and Manage Wikando Direct Debits](/platform-solutions-integrations/salesforce-nonprofit-cloud-npc/business-processes/initiate-and-manage-wikando-direct-debits) {% endhint %} {% hint style="info" %} Changes only apply to recurring donations that are processed through FundraisingBox and only the data relevant for the Connector is synchronized back once it is changed in Salesforce; the exact fields are listed in the [Standard Mapping table.](/platform-solutions-integrations/salesforce-nonprofit-cloud-npc/mapping-architecture/full-standard-mapping-table) {% endhint %} ### **Update Amount, Interval and Next Payment Date** * To update a recurring donation, create a new Gift Commitment Schedule for the corresponding Gift Commitment with the adjusted details using the standard action button 'Manage Gift Commitment Schedule'. * If the recurring donation has the payment method 'Wikando Direct Debit' use the action button 'Manage Wikando Direct Debit Schedules'. * To set the 'Next Payment Date' to a different date, select an 'Effective Start Date' for the new Gift Commitment Schedule accordingly. * To plan an update in advance, choose an 'Effective Start Date' in the future. The schedule will become active once the date arrives. {% hint style="info" %} Note that the 'Effective Start Date' of the new Gift Commitment Schedule must always be at least one day before the planned transaction date ('Transaction Day'). {% endhint %} ### **Update Bank Details of a 'Wikando Direct Debit' Recurring Donation** To change the bank details of a 'Wikando Direct Debit' recurring donation, use the action button 'Manage Wikando Direct Debit Schedules' to create a new Gift Commitment Schedule, and select the required Payment Instrument for it. ### **Reschedule the First Follow-Up Donation to an Earlier Date** The 'Start Date' of the active Gift Commitment Schedule is set directly in the input form to a date earlier than the current planned transaction ('Transaction Day'). The system then updates the 'Next Donation Date' shortly after midnight to reflect the new 'Start Date'. ### **Pause a Recurring Donation in Salesforce** Use the standard 'Pause' action button on the Gift Commitment and select a 'Pause From Date' and, if known, a 'Pause Till Date'. A Gift Commitment Schedule of type 'Pause Transactions' will be created and become active accordingly. ### **Resume a Recurring Donation** Use the standard 'Resume' action button on the Gift Commitment and select a 'Resume From Date'. A Gift Commitment Schedule of type 'Create Transactions' will be created and become active accordingly. ### **End a Recurring Donation** If the 'End Date' of the schedule is not already reached, or if it is set to today’s date for immediate termination, the status of the Gift Commitment can alternatively be changed to 'Closed' (or 'Failing' / 'Draft'). ### **Reactivate a Recurring Donation** If the recurring donation was ended because the Gift Commitment Schedule's 'End Date' was reached, the 'End Date' can be removed from that schedule. This will trigger a recalculation of the 'Next Transaction Date' based on the original recurring setup. If the donation was ended by changing the status of the Gift Commitment, the status can be set back to 'Active'. This will also trigger a recalculation of the 'Next Transaction Date' based on the original recurring setup. ### **Delete a Recurring Donation** Delete the recurring donation by deleting the corresponding Gift Commitment. {% hint style="danger" %} Once deleted, it **cannot be restored**. {% endhint %} # Initiate and Manage Wikando Direct Debits {% hint style="info" %} To activate 'Wikando Direct Debit' for your organization's FundraisingBox, please refer to [this article.](https://wikando.freshdesk.com/de/support/solutions/articles/79000127338) {% endhint %} ### **Prepare Required Bank Details** To initiate a 'Wikando Direct Debit' donation or recurring donation, a valid Payment Instrument containing the bank details must be created. The Payment Instrument can either be created during the creation of the Gift Transaction or Gift Commitment, or it can be created separately. To use the Payment Instrument for a 'Wikando Direct Debit', the following information must be provided: * The account to which the donation or recurring donation will be assigned (the same account must be selected when creating the Gift Transaction or Gift Commitment) * The account holder name of the bank account used * The bank account number (IBAN) * Selection of the Payment Instrument type 'Wikando Direct Debit' ### **Initiate a Wikando Direct Debit Donation** To initiate a 'Wikando Direct Debit' one-time donation via Salesforce, a new Gift Transaction must be created with the following information: * Create or select a Payment Instrument of type 'Wikando Direct Debit' * Select the same account linked to the Payment Instrument for the Gift Transaction * Select Payment Method 'Wikando Direct Debit' * Set Gift Transaction Status to 'Unpaid' * Enter the donation amount After saving, a SEPA mandate is created and the direct debit is submitted to the bank overnight. Once the payment is received, the 'Transaction Completion Date' is updated and the 'Gift Transaction Status' is changed to 'Paid.' ### **Initiate a Wikando Direct Debit Recurring Donation** To initiate a 'Wikando Direct Debit' recurring donation via Salesforce, a new Gift Commitment and Gift Commitment Schedule must be created with the following information: **For the Gift Commitment:** * Select the same account that is or will be linked to the required Payment Instrument * Set the Status to 'Active' **For the Gift Commitment Schedule:** * Create via the 'Manage Wikando Direct Debit Schedules' action button within the Gift Commitment created above * Create or select a Payment Instrument linked to the same account as the Gift Commitment * Select Payment Method 'Wikando Direct Debit' * Choose a valid Gift Transaction Period and Interval (Monthly/1, Monthly/3, Monthly/6, or Yearly/1) * Enter the donation amount * Set the 'Effective Start Date' and 'Transaction Day' accordingly, if the payment should be processed in the future rather than immediately * If applicable, select a valid SEPA mandate or leave the field empty After saving, the SEPA mandate (if not selected before) is created and the recurring direct debit is submitted to the bank overnight. ### Update Bank Details of a 'Wikando Direct Debit' Recurring Donation To change the bank details of a 'Wikando Direct Debit' recurring donation, use the action button "Manage Wikando Direct Debit Schedules" to create a new Gift Commitment Schedule, and select the required Payment Instrument for it. ### Switch Existing Recurring Donation to Automated Wikando Direct Debit {% hint style="info" %} Existing recurring donations from a different payment provider can be easily switched to automated processing via 'Wikando Direct Debit'. {% endhint %} To do so, a new Gift Commitment with a Gift Commitment Schedule containing the same information as the original recurring donation must be created, using 'Wikando Direct Debit' as the payment method. The process follows the same steps as initiating a new 'Wikando Direct Debit' recurring donation (see [Initiate a Wikando Direct Debit Recurring Donation](#initiate-a-wikando-direct-debit-recurring-donation)). If a SEPA mandate already exists for the original recurring donation and should continue to be used, its details, especially the Mandate reference number and signature date must be transferred to a newly created FundraisingBox SEPA mandate object or an existing FundraisingBox SEPA mandate, containing this information must be selected. If no SEPA mandate exists, one will be automatically created when the 'Wikando Direct Debit' recurring donation is initiated. Once saved, the processing of the recurring donation will continue seamlessly. # Manage P2P Fundraising Campaigns When a fundraiser creates a peer-to-peer fundraising campaign via FundraisingBox, the Connector automatically creates the related objects in Salesforce and links them accordingly. Once the campaign exists in Salesforce, it can be edited and controlled in different ways: ### Edit a P2P Fundraising Campaign {% hint style="info" %} Only the data relevant for the Connector is synchronized back once it is changed in Salesforce; the exact fields are listed in the [Standard Mapping table.](/platform-solutions-integrations/salesforce-nonprofit-cloud-npc/mapping-architecture/full-standard-mapping-table) {% endhint %} #### Edit in Salesforce Changes made directly within the Campaign fields in Salesforce are synchronized back to FundraisingBox for further processing. {% hint style="warning" %} The 'Thank you message', 'Campaign description', and 'Campaign image' are not synchronized from Salesforce. These must be updated via the FundraisingBox Edit Link provided within the campaign information. {% endhint %} #### Edit via FundraisingBox Edit Link * The FundraisingBox Edit Link can be found within any Campaign the Connector created. When the Campaign is updated via Edit Link, the changes will be reflected in Salesforce and the FundraisingBox for further processing. * Usually, updates made by the P2P fundraising campaign initiator are also done via the FundraisingBox Edit Link, when provided to the fundraiser. ### Control P2P Fundraising Campaign by Status Within the standard process the Campaign object gets the status 'In Progress' once it is initially created. The status can be controlled from Salesforce via the Campaign Status field. * Set P2P fundraising campaign as preferred by choosing the 'Preferred' Status * Set P2P fundraising campaign as locked by choosing the 'Aborted' or 'Planned' Status * Set P2P fundraising campaign as completed by choosing the 'Completed' Status * Set P2P fundraising campaign as active by choosing the 'In Progress' Status {% hint style="info" %} If you want to check the content and information of the fundraising campaign before it is published, you can ask for the feature 'Manual Activation'. With that, the campaigns will be created in 'Planned' status and need approval by setting the status to 'In Progress' in order to be published. {% endhint %} ### Delete a P2P Fundraising Campaign If a campaign created by the Connector is deleted in Salesforce, the Connector will also remove the corresponding fundraising campaign in FundraisingBox. {% hint style="danger" %} Once deleted, it **cannot be restored**. {% endhint %} # Failed and Reversed Transactions ### **Refunded Transactions** If a transaction is intentionally refunded via the organization’s PayPal or Stripe account, or in the case of a 'Wikando Direct Debit' via the organization’s bank account, the corresponding Gift Transaction status is automatically updated to 'Fully Refunded'. If a refund reason is provided by the payment provider, it is added to the transaction record. {% hint style="info" %} Refunds cannot be processed via FundraisingBox. They must be carried out directly through the respective payment provider or via the bank. {% endhint %} ### **Reversed Transactions** If a donor cancels their donation, for example via their own PayPal account or in the case of a 'Wikando Direct Debit' via their own bank account, the corresponding Gift Transaction status is automatically updated to 'Reversed'. If the payment provider provides a reason for the reversal, it is added to the transaction record. ### **Failed Transactions** If the payment provider reports an error, for example an expired credit card used for a recurring donation, the corresponding Gift Transaction status of the relevant follow-up transaction is automatically updated to 'Failed'. If the payment provider provides a reason for the failure, it is added to the transaction record. {% hint style="warning" %} The refund will terminate the recurring donation. If this is not desired, the affected recurring donation must be reactivated in Salesforce. {% endhint %} ### **Validation Errors** If a validation error occurs during data transmission, the connector creates a new entry in the 'FundraisingBox Connector Errors' object. The information provided in the errors object indicates how to resolve the validation error. {% hint style="info" %} Technical errors that prevent data transmission are not displayed in the 'FundraisingBox Connector Errors' object. They can be viewed through a separate Platform Solutions logging portal, see also [Error Handling & Log Viewer](/knowledge-base/error-log-and-log-viewer). {% endhint %} # Designations / Donation Purposes Designations (donation purposes) can be created and managed through the connector in several ways, depending on your system setup and preferences. {% hint style="info" %} The Project ID Code used in option 1-3 below typically represents a meaningful code or label used as a donation purpose, often already defined in an external system. The project name and Project ID Code can be identical. Information on creating ID codes in FundraisingBox is available [here](https://support.fundraisingbox.com/de/support/solutions/articles/79000145967-id-codes-anwendungsf%C3%A4lle-verwendung). Once configured, the process runs automatically. No further action is required from the FundraisingBox project team, allowing designations and donation purpose mappings to be created and adjusted flexibly. {% endhint %} ### **Option 1: Using an Existing Salesforce Gift Designation** A designation can be linked by directly referencing an existing Gift Designation in Salesforce. To use this option: * A Gift Designation has to be created in Salesforce. * The Gift Designation ID (retrievable from the Salesforce URL) has to be used as the Project ID Code in FundraisingBox. * The Project ID Code is then linked to a project in FundraisingBox. This project can subsequently be selected as a donation purpose within donation forms. ### **Option 2: Using a Unique Custom Field in Salesforce** Alternatively, a designation can be mapped using a custom identifier. For this option: * A custom field marked as 'unique' has to be created on the Gift Designation object in Salesforce. * A new Gift Designation is created and assigned a value in this unique field. * The same value is used as the Project ID Code in FundraisingBox. This allows flexible mapping without relying on Salesforce record IDs. ### **Option 3: Mapping via 'Donation Purpose' Field** Another approach is to use preconfigured project mappings within FundraisingBox. In this case, the Project ID Code is transferred automatically: * into the Gift Transaction (for one-time donations), or * into the Gift Commitment (for recurring donations), where all subsequent transactions will carry the same value, * or into the Campaign when created via a P2P fundraising campaign. Each project created in FundraisingBox must be assigned a corresponding Project ID Code. *** ### **Option 4: Mapping via Source ID Codes** As an additional option, Source ID Codes (Information on creating ID codes in FundraisingBox is available [here](https://support.fundraisingbox.com/de/support/solutions/articles/79000145967-id-codes-anwendungsf%C3%A4lle-verwendung)) can be used. These are configured in FundraisingBox and assigned to: * donation forms, or * P2P fundraising campaigns. The Source ID Code is then automatically transferred: * into the Gift Transaction, or * into the Gift Commitment (for recurring donations), where all follow-up donations inherit the same value. After initial setup, this process is fully automated. This allows sources to be managed and adjusted flexibly without further involvement from the FundraisingBox project team. *** ### **Option 5: Using Transaction Custom Fields in FundraisingBox** Designations can also be captured using custom fields defined in FundraisingBox. For this option: * A transaction custom field must be created in FundraisingBox. Learn [here](https://support.fundraisingbox.com/de/support/solutions/articles/79000127361-benutzerdefinierte-felder-anlegen-bearbeiten-archivieren-oder-l%C3%B6schen) how to configure custom fields in FundraisingBox. * The custom field must be activated in the donation form. The value entered by the donor can then be transferred via the connector and used for designation mapping in Salesforce. {% hint style="warning" %} Values from custom fields are automatically written to the corresponding raw data field. Direct mapping to a specific Salesforce field requires commissioning the FundraisingBox project team. {% endhint %}
# Bidirectional Data Flow Visualization & Data Touchpoints
### **Data Input** New or updated data such as online donations, recurring donation updates, donation reversals, or payment gateway payouts across all FundraisingBox channels automatically triggers a webhook to the FundraisingBox NPC Connector. To avoid duplicates, a two-step duplicate check is integrated. Learn more about our [duplicate management.](/knowledge-base/duplicate-management) ### **Donation Data Processing** The Connector processes incoming data and updates the corresponding Salesforce NPC objects in real time. To enable seamless synchronization, the Connector maintains internal mappings and manages relationships and processing sequences between FundraisingBox and Salesforce objects. This ensures consistent, reliable, and accurate creation and updates of records across both systems. ### **Bidirectionality** For inbound data from Salesforce, the Connector leverages filtered Streaming API PushTopics to capture only relevant changes. Manual updates made in Salesforce are automatically synchronized back to FundraisingBox, helping maintain data integrity and minimizing duplicate records. This bidirectional synchronization ensures that downstream processes such as account adjustments, updates for recurring payment or even triggering automatic direct debit collection run smoothly and reliably. ### **Error Logs** In cases where data cannot be processed, error logs are generated to provide detailed information for efficient issue resolution. Depending on the nature of the issue, these logs are available either in the FundraisingBox Error Log within Salesforce or in the FundraisingBox Log Viewer. [Learn more about our error logs.](/knowledge-base/error-log-and-log-viewer) # Extended Data Model FundraisingBox Platform Solutions extended Data Model for the Salesforce Nonprofit Cloud The Connector is based on the Salesforce Nonprofit Cloud data model. The objects from the standard data model highlighted in green in the diagram are used by the connector to store data from FundraisingBox, establish relationships, and apply the logic embedded in the data model. In order to enable the full use of FundraisingBox functions via the Connector, the Salesforce Nonprofit Cloud data model has been extended with additional key objects.
When a donation occurs, the FundraisingBox Nonprofit Cloud Connector transfers structured records into Salesforce, including: * **Person Accounts** for private donors * **Business Accounts** for organizational donors * **Gift Transactions** for each single donation * **Payment Instruments** for payments with bank details * **SEPA Mandate (FundraisingBox object)** for SEPA direct debit details * **Gift Commitments** for recurring donations * **Gift Commitment Schedules** with amount, frequency and timing details of the recurring donation * **Campaigns** for FundraisingBox P2P fundraising campaigns * **Gift Designations** for donation purposes * **Gift Refunds** for refund information linked to the initial gift transaction * **Payouts (FundraisingBox object)** for reconciliation data of e.g. stripe batch payouts * **FundraisingBox Connector Errors (FundraisingBox object)** for validation error notification At the same time, relevant updates from Salesforce are synchronized back to FundraisingBox, enabling a consistent and unified data experience. # Mapping Architecture For each object from FundraisingBox, the corresponding standard objects in Salesforce are referenced and processed. This standardized mapping ensures that all data from FundraisingBox is consistently structured and reliably stored in the correct location within Salesforce. | Salesforce NPC Object | Fbox Object | Description | | -------------------------------------------- | -------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | Person Account | FundraisingBox Contact (Private Donation) | Corresponds to the FundraisingBox contact for private donations. | | Organization (Business) Account | FundraisingBox Contact (Organizational Donation) | Corresponds to the FundraisingBox contact for organizational donations. | | Gift Transaction | FundraisingBox Transaction | Corresponds to the FundraisingBox transaction. | | Gift Commitment and Gift Commitment Schedule | FundraisingBox Recurring Donation | The Gift Commitment represents the donor’s intent and recurring donation meta data, while the Gift Commitment Schedule defines its payment schedule. | | Campaign | FundraisingBox Fundraising Campaign (P2P Campaign) | Corresponds to the FundraisingBox fundraising campaign. | # Fbox Customized Objects ## Extension of the Salesforce Nonprofit Cloud Data Model Since the standard data model of Salesforce Nonprofit Cloud does not cover all relevant business processes of a nonprofit organization, the FundraisingBox Nonprofit Cloud Managed App extends the model with FundraisingBox **Custom Objects** and **Custom Fields**. ### **FundraisingBox Custom Objects** | FundraisingBox Custom Object | Description | | ----------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | **SEPA Mandate** | Created for each single and recurring SEPA direct debit donation. | | **Payout** | The Payout object reconciles batch payout details (including provider fees) and links them to the related individual transactions. | | **FundraisingBox Connector Errors** | The Connector logs errors for transmitted records with validation issues to notify the donor service for resolution. | #### Select Object for more details {% tabs %} {% tab title="SEPA Mandate" %}
LabelSalesforce FieldFBox Object.FieldTypeDescription
SEPA Mandate NameNamefbMandate.referenceIdText(80)Corresponds to the mandate reference number
Statusfbox__Status__cfbMandate.mandateStatusPicklistStatus of the Mandate
Holder Namefbox__Holder_Name__cfbMandate.bankAccountOwnerText(255)Name of the account holder as entered in the donation form
Payment Instrumentfbox__Payment_Instrument__cLookup(Payment Instrument)Link to the payment instrument in Salesforce
FRB Linkfbox__FRB_Link__cURL(255)Download link of the SEPA Mandate.
Date signedfbox__Date_signed__cfbMandate.signatureDateDateDate on which the SEPA Mandate becomes active (usually the creation date)
Mandate reference numberfbox__Mandate_ID__cfbMandate.referenceIdText(35)Automatically generated and unique mandate reference number
Typefbox__Type__cfbMandate.transactionTypePicklistDefines the type of mandate: One-time or Recurring
FundraisingBox Idfbox__FundraisingBox_Id__cfbMandate.idText(40)

ID of the FundraisingBox object

{% endtab %} {% tab title="Payout" %} | Label | Salesforce Field | FBox Object.Field | Type | Description | | -------------------------- | ------------------------------------------ | ------------------------------------------------------------------------------ | ---------------------- | ------------------------------------------------------------------------------- | | Payout Name | Name | fbPayout.fbTypeId + fbPayout.amount + fbPayout.currency + fbPayout.createdTime | Text(255) | Name of the individual payout object | | Amount Donations Fee | fbox\_\_Amount\_Donations\_Fee\_\_c | fbPayout.amountDonationsFee | Number(16, 2) | Total of the payment service fees for the disbursed donation (negative amount). | | Amount Donations | fbox\_\_Amount\_Donations\_\_c | fbPayout.amountDonations | Number(16, 2) | Total of the original donation amounts for the disbursed donation. | | Amount Unknown | fbox\_\_Amount\_Unknown\_\_c | fbPayout.amountUnknown | Number(16, 2) | Total amount of unknown transactions within a payout. | | Payout Amount | fbox\_\_Amount\_\_c | fbPayout.amount | Number(16, 2) | Total amount transferred to the organization’s account. | | Currency | fbox\_\_Currency\_\_c | fbPayout.currency | Text(10) | Currency of the amount transferred to the organization’s account. | | Donation Count | fbox\_\_Donation\_Count\_\_c | fbPayout.donations | Number(18, 0) | Number of disbursed donations in a payout. | | External Payout Id | fbox\_\_External\_Payout\_id\_\_c | fbPayout.externalPayoutId | Text(255) | ID provided by the payment service. | | Payment Provider | fbox\_\_Payment\_Provider\_\_c | fbPayout.fbTypeId -> Mapped | Text(255) | Name of Payment Provider | | Payout Created Time | fbox\_\_Payout\_Created\_Time\_\_c | fbPayout.createdTime | Date/Time | Timestamp when the payout was created by the payment service. | | FundraisingBox Id | fbox\_\_FundraisingBox\_Id\_\_c | fbPayout.Id | Number(18, 0) | ID of the FundraisingBox object. | | Donations and Fees RawData | fbox\_\_Donations\_and\_Fees\_RawData\_\_c | | Long Text Area(131072) | Internal field for further processing in Salesforce. | | {% endtab %} | | | | | {% tab title="FundraisingBox Connector Errors" %} | Label | Salesforce Field | Type | Description | | ------------------------ | --------------------------------------- | -------------------------------- | ---------------------------------------------------------------------------------------- | | Account | fbox\_\_Account\_\_c | Lookup(Account) | Link to the (Person or Business) account where the error occurred. | | Additional Data | fbox\_\_Additional\_Data\_\_c | Long Text Area(131072) | Detailed description of the error. | | Campaign | fbox\_\_Campaign\_\_c | Lookup(Campaign) | Link to the fundraising campaign where the error occurred. | | Connector Sync Reference | fbox\_\_Connector\_Sync\_Reference\_\_c | Text(64) | Unique identifier of the connector process. | | Error Code | fbox\_\_Error\_Code\_\_c | Text(64) | A code that identifies the type of error. | | Name | fbox\_\_Name\_\_c | Auto Number | Sequential numbering to uniquely identify an error entry. | | FundraisingBoxObjectId | fbox\_\_FundraisingBoxObjectId\_\_c | Text(18) | ID of the FundraisingBox object associated with the error. | | FundraisingBoxObjectId | fbox\_\_FundraisingBoxObjectName\_\_c | Text(255) | Name of the FundraisingBox object associated with the error. | | Message | fbox\_\_Message\_\_c | Text(255) | Short description of the error. Detailed information is stored in Additional\_Data\_\_c. | | Gift Transaction | fbox\_\_Gift\_Transaction\_\_c | Lookup(Transaction) | Link to the gift transaction where the error occurred. | | Payment Instrument | fbox\_\_Payment\_Instrument\_\_c | Lookup(Payment Instrument) | Link to the payment instrument where the error occurred. | | Gift Commitment | fbox\_\_Gift\_Commitment\_\_c | Lookup(Gift Commitment) | Link to the gift commitment where the error occurred. | | Gift Commitment Schedule | fbox\_\_Gift\_Commitment\_Schedule\_\_c | Lookup(Gift Commitment Schedule) | Link to the gift commitment schedule where the error occurred. | | Salesforce Error Message | fbox\_\_Salesforce\_Error\_Message\_\_c | Long Text Area(131072) | The exact Salesforce error message received by the connector. | | SEPA Mandate | fbox\_\_SEPA\_Mandate\_\_c | Lookup(SEPA Mandate) | Link to the SEPA Mandate where the error occurred. | | {% endtab %} | | | | | {% endtabs %} | | | | # Fbox Customized Fields ### **FundraisingBox Custom Fields in Salesforce Standard Objects** For certain market-specific information no corresponding fields exist in the standard Salesforce data model. To ensure that this information is available in Salesforce after a donation is received, the data model has also been extended with FundraisingBox-specific **Custom Fields** {% hint style="info" %} The **FundraisingBox ID fields** are primarily intended for informational purposes. They are used by both the connector e.g., to filter relevant updates based on FundraisingBox IDs and the donation service, for purposes such as data traceability. These ID fields must not be modified. Ideally, they should be configured as read-only. Any changes made to FundraisingBox IDs via the Salesforce user interface do not affect the connector’s internal ID mapping logic. The mapping itself remains unchanged, regardless of any manual modifications to these IDs. {% endhint %} #### Select object for more details {% tabs %} {% tab title=" Account" %}
LabelSalesforce FieldFBox Object.FieldTypeDescription
Email Opt In Statusfbox__Email_Opt_In_Status__cfbPersonEmailAddress(main).doiStatusPicklistSet when DOI (Double Opt-In) is active in Fbox
Wants Newsletterfbox__Wants_Newsletter__cfbPersonEmailAddress(main).wantsNewsletterCheckboxSet when SOI (Single Opt-In) is active in Fbox
FundraisingBox Idfbox__FundraisingBox_Id__cfbPersonIdText(40)ID of the FundraisingBox object
RawDatafbox__RawData__cfbPerson.fb_custom_fieldsLong Text Area(131072)Raw values from custom contact fields
{% endtab %} {% tab title="Gift Transaction" %} | Label | Salesforce Field | FBox Object.Field | Type | Description | | ------------------------ | ----------------------------------- | ----------------------------------------------------- | ---------------------- | --------------------------------------------------------------------------------- | | SEPA Mandate | fbox\_\_SEPA\_Mandate\_\_c | fbMandate.referenceId | Lookup(SEPA Mandate) | Link to the SEPA mandate | | Donation Receipt Request | fbox\_\_DonationReceiptRequest\_\_c | fbDonation.ReceiptStatus | Picklist | Set if provided via donation form | | Donation Purpose | fbox\_\_DonationPurpose\_\_c | fbDonation.PromotionCode | Text(255) | Set if provided via donation form and Project ID code is stored in FundraisingBox | | Donor Message | fbox\_\_DonorMessage\_\_c | fbDonation.meta\_info.message | Long Text Area(131072) | Set if provided via donation form | | Shop Cart Content | fbox\_\_ShopCartContent\_\_c | fbDonation.CustomField | Long Text Area(131072) | Cart contents are read from a preconfigured cart custom field | | Related Payout | fbox\_\_RelatedPayout\_\_c | Salesforce ID des Payouts | Lookup(Payout) | Linked if reconciliation is active | | Gateway Processing Fee | fbox\_\_GatewayProcessingFee\_\_c | Gebühren dieser Transaktion aus dem Payout | Currency | Für PayPal und Stripe, wenn Reconciliation aktiv ist | | FundraisingBox ID | fbox\_\_FundraisingBox\_Id\_\_c | fbDonationId | Text(40) | ID of the FundraisingBox object | | RawData | fbox\_\_RawData\_\_c | fbDonation.fb\_custom\_fields & fbDonation.meta\_info | Long Text Area(131072) | Raw values from FundraisingBox custom transaction fields and transaction metadata | | {% endtab %} | | | | | {% tab title="Payment Instrument" %} | Label | Salesforce Field | FBox Object.Field | Type | Description | | ----------------- | ------------------------------- | --------------------------------------------------------------------- | -------- | ------------------------------- | | FundraisingBox ID | fbox\_\_FundraisingBox\_Id\_\_c | ba+FbPersonBankAccountID, ma+FbMandateID oder cc+FbPersonCreditCardID | Text(40) | ID of the FundraisingBox object | | {% endtab %} | | | | | {% tab title="Gift Commitment" %} | Label | Salesforce Field | FBox Object.Field | Type | Description | | ----------------- | ------------------------------- | --------------------------------------------------------------------- | ---------------------- | -------------------------------------------------------------------------------------------- | | Cancel Reason | fbox\_\_CancelReason\_\_c | fbRecurringPayment.meta\_info.cancel\_reason | Text(255) | If recurring donation is canceled via the donor’s own PayPal account | | FundraisingBox ID | fbox\_\_FundraisingBox\_Id\_\_c | recurringPaymentId | Text(40) | ID of the FundraisingBox object | | RawData | fbox\_\_RawData\_\_c | fbRecurringPayment.fb\_custom\_fields & fbRecurringPayment.meta\_info | Long Text Area(131072) | Raw values from custom recurring donation/transaction fields and recurring donation metadata | | {% endtab %} | | | | | {% tab title="Gift Commitment Schedule" %} | Label | Salesforce Field | FBox Object.Field | Type | Description | | ----------------- | ------------------------------- | --------------------- | -------------------- | ------------------------------- | | SEPA Mandate | fbox\_\_SEPA\_Mandate\_\_c | fbMandate.referenceId | Lookup(SEPA Mandate) | Link to the SEPA mandate | | FundraisingBox ID | fbox\_\_FundraisingBox\_Id\_\_c | recurringPaymentId | Text(40) | ID of the FundraisingBox object | | {% endtab %} | | | | | {% tab title="Campaign" %} | Label | Salesforce Field | FBox Object.Field | Type | Description | | ----------------------------- | -------------------------------------------------------- | ------------------------------------ | --------------------- | ----------------------------------------------------------- | | Fundraising page edit link | fbox\_\_Fundraising\_Page\_Edit\_Link\_\_c | fbFundraisingPage.adminLink | URL(255) | Fundraising campaign edit link | | Fundraising page image url | fbox\_\_Fundraising\_Page\_Image\_Url\_\_c | fbFundraisingPage.imageUrl | URL(255) | URL of the fundraising campaign image | | Fundraising page image | fbox\_\_Fundraising\_Page\_Image\_\_c | image | Formula (Text) | Formula field for displaying the fundraising campaign image | | Public name of the fundraiser | fbox\_\_Fundraising\_Page\_Fundraiser\_Public\_Name\_\_c | fbFundraisingPage.fundraiserName | Text(255) | Public name of the fundraising campaign creator | | Thank you Message | fbox\_\_Thank\_you\_Message\_\_c | fbFundraisingPage.donationMessage | Long Text Area(32768) | Fundraising campaign creator's Thank-you message | | FundraisingBox ID | fbox\_\_FundraisingBox\_Id\_\_c | fbFundraisingPageId | Text(40) | ID of the FundraisingBox object | | RawData | fbox\_\_RawData\_\_c | fbFundraisingPage.fb\_custom\_fields | Long Text Area(32768) | Raw values from custom donation campaign fields | | {% endtab %} | | | | | | {% endtabs %} | | | | | # Full Standard Mapping Table The full mapping architecture of the FundraisingBox Nonprofit Cloud Managed Package is summarized in a standard mapping table. This table provides a detailed field-level representation of the architecture. Please access the table here: [Full Standard Mapping Table](https://docs.google.com/spreadsheets/d/1XiC6p_Fx2sJOX0JYWi2MmafMirlJOPWbsnIP5MrVUVk/edit?gid=795485192#gid=795485192) {% hint style="info" %} Every integration project is based on the standard mapping architecture. Within a customer project it serves as the central documentation of the target state and, upon project completion, as the documentation of the actual state. {% endhint %} # Salesforce Nonprofit Success Pack (NPSP) More information will be available soon. The FundraisingBox Connector for Salesforce NPSP is already fully available and in use. If you’re interested in more information, please feel free to [contact our support team](https://fundraisingbox.com/kontakt/). # System Setup # Data Model # Data Flow # Business Processes # Microsoft Dynamics More information will be available soon. The FundraisingBox Connector for Microsoft Dynamics is already fully available and in use. If you’re interested in more information, please feel free to [contact our support team.](https://fundraisingbox.com/kontakt/) # System Setup # Data Model # Data Flow # Business Processes # Feature Set ### Platform Solutions – Feature Set The Platform Solutions follows a modular, building-block architecture. ### **Multi-Channel Fundraising Touchpoints** **Donation Forms** * Real-time transfer of one-time and recurring donations, as well as contact data, from any number of FundraisingBox forms * Integration of FundraisingBox duplicate detection, enhanced by preconfigured duplicate rules within the target system * Synchronization of standard information (see standard mapping table), such as email opt-ins, donation receipt preferences, donation purposes, etc. * Transfer of data from custom form fields **Fundraising Campaigns** * Automatic synchronization of fundraising campaigns, including all relevant campaign data and the campaign creator, as campaign records * Incoming donations are directly linked to the corresponding campaign * Campaigns can be managed from within the target system, e.g. adjusting fundraising goals, modifying campaign duration, or controlling publication and deactivation **Charity Shop** * Synchronization of individual donation products from the digital shopping cart of the charity shop connected to the donation forms, including associated donation data **Custom Applications** * Synchronization of data collected via organization-specific applications connected to the donation forms **Bundled Raw Data** * In addition to standard information, custom fields and metadata of a donation are automatically transferred as bundled JSON datasets per object * Enables flexible, connector-independent downstream processing without requiring additional requests **Contact/Account Data Management** * Thanks to bidirectional synchronization, updates to contact data submitted via FundraisingBox online forms are automatically written back * Ensures that duplicate detection continues to function reliably for future donations, helping prevent duplicate records *** ### **Payment Operations** **Support for Multiple Payment Methods** * Integration of various payment options, including PayPal, direct debit, credit cards, Apple Pay, Google Pay, TWINT, and others * Payments are processed directly by the payment provider and transferred to the organization’s account, ensuring fast fund availability **Recurring Payment Management** * Cancellation, pausing, reactivation, and adjustments (e.g. amount or interval) of recurring donations can be managed directly within the system * Bidirectional synchronization ensures that updates are transmitted to the original payment provider and executed accordingly **Reconciliation** * Automatic identification and allocation of payout batches to the organization’s account * Mapping of individual transactions to their respective payouts * Capture and linkage of payout data, including transaction-level and payout-level fee transparency **Direct Debit Processing (Automated)** * Fully automated handling of one-time and recurring direct debit donations * Automatic generation of SEPA-compliant mandates * Synchronization of direct debit donations and mandates for visibility and management within the system * Ability to initiate direct debit collections directly from the system (e.g. for offline direct debits) * Migration of existing recurring direct debit agreements to automated processing **Manual Direct Debit Processing** * Direct debit data can also be transferred and processed when handled manually or via third-party providers **Bank Sync (Offline Donations)** * Import of offline donations (e.g. bank transfers) via bank synchronization * Donation data can be reviewed and transferred into the system with a single click **SEPA Mandate Management** * Structured storage of SEPA mandate information, including all relevant details * Linking of mandates to payment instruments and associated transactions **Error Logging and Chargeback Handling** * Documentation of validation errors and troubleshooting information directly within the system * Updates on failed or reversed payments, including chargeback reasons where provided by the payment provider *** ### **Customer Relationship Features** **Donor Portal for Online Contacts** * Donors submitting data via FundraisingBox forms gain access to a personal overview of their donations and recurring contributions * Visibility into donation details such as amount, date, and purpose * Ability to manage existing recurring donations * Direct access to issued donation receipts for transparency * Self-service updates of personal data (e.g. name, address) * Simplified process for making additional donations with just a few clicks # Testing the Data Flow This section describes how to execute test scenarios to verify the data flow between FundraisingBox and the CRM system. ### **Creating Test Donations via FundraisingBox** {% hint style="info" %} The test donations described here use the payment method 'direct debit'. If additional payment methods are to be tested, they must be enabled for the FundraisingBox donation forms in sandbox mode. More information can be found [here](https://support.fundraisingbox.com/de/support/solutions/folders/79000086061). {% endhint %} **Procedure for testing a direct debit donation** * Log in at: [https://secure.fundraisingbox.com/login](https://secure.fundraisingbox.com/login?lan=en) using your credentials. These must be requested from the account admin. * Select the menu item 'Forms' in the left navigation bar and choose or create a donation form. * Open the form preview via 'Preview' and complete the form using the following sample data: * Payment method: SEPA direct debit * Test IBAN: 121212 (identifies a test donation) or alternatively use a sample IBAN (and BIC if required) * Submit the form * The success page will be displayed * Verify the transaction via the 'Transactions' menu item and enable the toggle 'Show test transactions only' when using the test IBAN 121212 **Result:**\ The transaction is created in the CRM system as a 'Gift Transaction'. Changes to relevant fields (e.g., first name or last name) in the CRM system are synchronized back to FundraisingBox. *** ### **Creating a Peer-to-Peer Fundraising Campaign** * Navigate to the menu item 'Fundraising campaigns' and, under 'Settings', select a preconfigured fundraising campaign tool * Open the preview, select 'Create a new campaign', and complete and save the form **Result**: * The campaign appears immediately in FundraisingBox. * Shortly thereafter, a corresponding Campaign is also created in the CRM system. * The campaign creator is linked as a CampaignMember, and incoming donations through this campaign are automatically assigned. * Changes in the CRM system are synchronized back to FundraisingBox, provided they are defined as bidirectionally syncable in the Standard Mapping table. * Non-syncable properties (e.g., image, description) can be edited via the edit link or directly in FundraisingBox. In test mode, login is required for this. # Duplicate Management ### **First Matching in FundraisingBox** When new data is submitted via a FundraisingBox form, the first duplicate check is performed directly in FundraisingBox according to the FundraisingBox duplicate rules. This means that in order for a contact to be uniquely identified, at least one of the following criteria must be met: * Same first & last name **+** same email address * Same first & last name **+** same postal address * Same first & last name **+** same bank account (IBAN) If a duplicate is detected, new information such as updated address details can still be stored. Based on this logic, the data is then passed on to Salesforce via the Connector. **Avoiding Duplicate Organization/Company Accounts** The creation of duplicate organization accounts is also prevented. For example, if two employees from the same organization donate separately, no additional organization account is created in Salesforce. Instead, both individuals are created as separate contacts and linked to the same organization account. Requirements for this: * The organization name must be written exactly the same way. * At least one of the following must also match: * Email address * Postal address * Bank account (IBAN) **Exceptions to Automatic Duplicate Merging** In certain cases, potential duplicates are not automatically merged: * Company employee: For each donation made on behalf of a company, a new contact is created for the respective employee, as only the company contact is linked within FundraisingBox. If the same contact person makes another company donation, duplicate detection in Microsoft must prevent the creation of duplicate records. * Salutation: If different salutations are provided, a new contact is created. * Example: An existing contact donates as *“Ms”*, but later donates as *“Non-binary”* → no merge occurs. * If the salutation field is left blank in the form, the merge still happens automatically. * Custom Contact Fields: If custom fields are used and the provided value does not match exactly, a new contact is created. * Example: An existing contact has a *“Membership Number”* value. If a new, different number is entered via the form → no merge occurs. * If the custom field did not exist previously for the contact, the record is merged and the new field value is added. *** ### **Second Matching in Salesforce Nonprofit Cloud** A second duplicate check takes place in Salesforce. Here, the Connector uses the duplicate rules defined in Salesforce (either standard or custom rules). Before creating a new record, the Connector checks the configured Salesforce duplicate rules. If the contact already exists, it is identified and updated with the new information. The Connector documents the mapping between contacts using ID mapping. Summary: * If an existing FundraisingBox contact is identified during the first check, the Connector transfers its information to the corresponding Salesforce contact via ID mapping. * If a new FundraisingBox contact with a new FundraisingBox Contact ID is created, the Connector attempts to create a new record in Salesforce. * If Salesforce blocks the creation due to a duplicate error, the Connector analyzes Salesforce’s duplicate results. The Salesforce duplicate rules then apply. * The Connector retrieves the ID of the first matching contact and links it to the record. Instead of creating a duplicate, an update is performed. *** ### **Additional Use Cases** * **Manual contact creation followed by a donation:** The Connector attempts to create the contact again. This triggers Salesforce’s duplicate check based on the defined rules, even if the contact already exists from another source (e.g., an offline donation). * **Contact created by the Connector after a donation, followed by manual contact creation:** Again, Salesforce’s duplicate rules are applied. This also applies if duplicates are merged for other reasons (e.g., different email addresses, typos in names). * **Manual merging or migration of contacts by the user:** Depending on the Connector’s knowledge of the “winner” (remaining contact) and the “loser” (deleted contact), it adjusts the mappings accordingly. *** ### **Duplicate management for payment objects** * **Credit card:** For each new credit card donation, a new payment object is created by default even if the cardholder or donor is the same.\ If the creation of multiple credit card payment objects should be prevented, a duplicate rule must be defined in Salesforce. The connector respects this rule and will not create a new payment object in such cases. * **Direct debit:** For direct debit donations, a new payment object is only created if the account holder differs from an existing one. Otherwise, the connector reuses the existing payment object. # Error Log & Log Viewer Two different error handling mechanisms are available, depending on the type and origin of the issue. Together, these mechanisms ensure full transparency across all error scenarios. ### **FundraisingBox Connector Error Log (Validation Errors)** Validation errors occur when transmitted data does not meet the validation rules of the target system. In this case, all objects intended for transmission are still created. To enable this, effected data may be adjusted (e.g. by omitting or truncating values), and adjustments documented. In these cases, the connector creates an entry in the **FundraisingBox Connector Errors** object. * Captures data-related validation issues (e.g. invalid field values) * Provides guidance on how to resolve the specific error * Enables structured tracking and resolution of data inconsistencies Technical errors that prevent transmission are **not** logged here and must be reviewed in the Log Viewer or external logging tools. ### **FundraisingBox Log Viewer (Synchronization & System-Errors)** The FundraisingBox Connector Log Viewer provides a centralized overview of all synchronization events, including both successful and failed data transfers. It is primarily used to monitor and analyze issues related to data transmission between systems. * Displays all relevant sync events and their status * Provides error messages with context to support root cause analysis {% hint style="info" %} During setup and testing phases, errors can be independently reviewed and analyzed via the Log Viewer. In live operation, FundraisingBox actively monitors transmission errors and, where possible, resolves them or communicates them to the responsible parties. {% endhint %} Access to the FundraisingBox Connector Log Viewer is granted by the FundraisingBox project team. # Project Management The following steps describe the common implementation process for the platform solutions via connector interface at a detailed level. {% hint style="info" %} **Checklist Salesforce Implementation Project** This checklist serves as a guide for the structured execution of the implementation project. It includes the key tasks and requirements that must be fulfilled by both the organization and the agency throughout the course of the project. View the checklist for * Salesforce NPC projects [here.](https://docs.google.com/spreadsheets/d/162bQGZC0WijQLg_BRbVlGToYXi5ScTp4mep4FMivV74/edit?gid=0#gid=0) * Salesforce NPSP projects [here](https://docs.google.com/spreadsheets/d/1-Q9xJwU6FqQmozip5AgqGJOIde5BSAcqVRsfPZ0mlWQ/edit?gid=0#gid=0). {% endhint %} The purpose of this process description is to provide implementation partners with a clear understanding of how the implementation is expected to proceed, which responsibilities lie with which parties, and which scope of work can be derived from each phase. It serves as a practical guideline for planning, coordination, execution, and effort estimation throughout the project. ## Project Setup ### Step 1: **Project Setup, Alignment & Planning** **Objective:** To establish a clear project structure, aligned expectations, and a coordinated execution framework. * Align on project setup, roles, responsibilities, involved systems, and high-level timeline * Establish project management setup, including tools, access, and stakeholder alignment * Define and document milestones, timelines, and responsibilities to ensure transparent and efficient execution ### Step 2: Establishing a Shared Understanding **Objective:** To ensure a shared understanding of both the technical possibilities and the organizational requirements, forming the basis for all subsequent implementation steps. The following activities are carried out: * Introduction and, if applicable, testing of the [FundraisingBox Platform Solutions features](/knowledge-base/feature-set) * Presentation of fundraising- and payment-related solutions that are not part of the Salesforce NPC standard, where applicable * Review of the organization’s standard business processes and identification of key pain points related to the implementation * Derivation of clear requirements for the implementation ### Step 3: **Scope Definition, Target State & Architecture** **Objective:** To establish a precise functional and technical blueprint of the interface, ensuring clarity on scope, design, and implementation approach. * Define connector scope, customizations, and out-of-scope boundaries * Detail target state via data mapping, aligning use cases and documenting in a customized mapping table * Translate into implementation architecture, creating a clear mapping concept as foundation ## System Setup ### **Step 4: Test Environment Setup, Integration & Validation** **Objective:** To establish a functional test setup and validate the integration in a controlled environment. * Set up test environments, including system instances, feature activation, and required configurations * Implement and connect the connector between FundraisingBox and the target CRM system * Validate bidirectional data transfer and test defined use cases and processes to ensure proper functionality ### **Step 5: Initial Data Synchronization** **Objective:** To establish a consistent and aligned data foundation across systems by setting up an initial ID mapping for reliable synchronization. * Migrate existing FundraisingBox data into the target CRM test instance * Align on and prepare ID matching of data between FundraisingBox and the target CRM system * Provide and document ID mapping for FundraisingBox to ensure accurate data synchronization ### Step 6: **Final Refinement of the Prototype** **Objective:** To finalize and stabilize the connector through comprehensive testing and targeted optimizations, ensuring readiness for go-live. * Perform extensive testing, including edge cases, in a near real-life environment * Implement necessary adjustments and optimizations based on test results * Validate stable and reliable data transfer, confirming readiness for transition to the live environment ### **Step 7: Go-Live** **Objective:** To deploy the connector into the production environment and initiate stable live operation. * Set up and configure production environments based on validated test setups * Import data and apply the established ID mapping (as in step 5) * Establish connection and initiate bidirectional synchronization between systems # Initial Data Mapping & Synchronization The initial data mapping and synchronization is a one-time setup process that maps existing records between FundraisingBox and the CRM system. It ensures the connector can identify corresponding objects on both sides. {% hint style="info" %} The initial step does not harmonize data between the systems; it only establishes fixed relationships as the foundation for subsequent automated synchronization. {% endhint %} ### Scenarios and Approach {% hint style="warning" %} The initial data synchronization is critical for ensuring a smooth integration. If Scenario 3 or 4 applies to your project, it is mandatory to carry this out. Otherwise, a go-live will not be possible. {% endhint %} #### Scenario 1: No Data in FundraisingBox In this case, no initial mapping is required. Once the integration is activated, data will be automatically synchronized from FundraisingBox to the CRM system according to the defined mapping. #### Scenario 2: Small to Medium Data Volumes Existing Only in FundraisingBox For small to medium volumes of donations (up to approx. 50,000 records/transactions) that exist exclusively in FundraisingBox, the transfer of online and offline donations (Wikando Bank Sync) as well as campaign data is initiated by the FundraisingBox team. Records that were manually created in FundraisingBox are not transferred. #### Scenario 3: Large Data Volumes Existing Only in FundraisingBox For large volumes of data (from approx. 50,000 records/transactions), the FundraisingBox data is first transferred to the CRM system by the implementation partner or the organization's data migration team. In this process, FundraisingBox data must be exported together with the corresponding IDs (fbPerson ID, fbDonation ID, fbRecurringPayment ID, fbFundraisingPage ID) and then imported into the CRM system, for example via manual import. Afterwards, the implementation partner or the organization's data migration team must create an ID mapping documentation, which is handed to the FundraisingBox project team and stored in the connector to correctly match records and prevent duplicates once the inital synchronization has started. #### Scenario 4: FundraisingBox Data Migrated From a Legacy CRM System Into the New CRM System It must be determined where the most up-to-date data resides (legacy CRM system, FundraisingBox, or the new CRM system). If the most current data is not in FundraisingBox, the data in FundraisingBox must first be updated to reflect the current state. Afterwards, FundraisingBox data must be exported (from the leading system) together with the corresponding IDs (fbPerson ID, fbDonation ID, fbRecurringPayment ID, fbFundraisingPage ID) and then imported into the CRM system, for example via manual import. The implementation partner or the organization's data migration team must create an ID mapping documentation, which is handed to the FundraisingBox project team and stored in the connector to correctly match records and prevent duplicates once the inital synchronization has started. ### **Step-by-step Guide for Scenario 3 and 4** * **Starting point:** The most up-to-date data resides in the legading CRM system. * **Data export and import:** FundraisingBox Data is exported from the leading CRM system and imported into the new CRM system. * FundraisingBox data is exported together with the corresponding IDs (fbPerson ID, fbDonation ID, fbRecurringPayment ID, fbFundraisingPage ID). * **ID mapping documentation:** In a CSV file, the FundraisingBox IDs are mapped to the corresponding IDs in the CRM system. The documenation is handed to the FundraisingBox project team (example ID mapping file will be prepared). * **FundraisingBox update:** The data in FundraisingBox is updated to match the state of the new CRM system. * **Connector import:** FundraisingBox project team imports the CSV file with the ID mappings into the connector. **Delta period:** There will be a time gap between the last data transferred via the old process (FundraisingBox → legacy CRM system → new CRM system) and the project Go-Live. Data from this period will be transferred manually at Go-Live by the FundraisingBox project Team. For this purpose, the exact timestamp or the reference to the last donation imported from the legacy CRM system into the new CRM system is required. * **Start of synchronization:** The connector begins synchronizing data between the systems. *** ### Important Steps Before Bidirectional Live Synchronization / Go Live It is strongly recommended to first perform the initial data mapping and synchronization in a test instance of the CRM system. The connector can initially be connected unidirectionally (from the live FundraisingBox to the CRM test instance). This allows all processes to be tested under realistic conditions and potential issues to be identified and resolved at an early stage. # FundraisingBox REST API The Platform Solutions connections are based on the FundraisingBox REST API. To access the API documentation please click [here](https://developer.fundraisingbox.com/reference/introduction-json). # Release Notes # Additional Permission Set for Salesforce Standard Objects & Fields ### Add Permission set for required permissions for Salesforce standard fields and objects Standard field and object permissions cannot be packaged in Salesforce, so an [additional permission set](https://docs.google.com/spreadsheets/d/1Io2mgIrJjnXvFcmV_E167DqQlHQYHWM_cyGqDuLAccg/edit?gid=0#gid=0) has to be created to allow the Connector user access to all required objects and fields. You can create this manually, but we suggest importing our XML file as documented in the 5 steps below. {% stepper %} {% step %} #### Prepare your environment Ensure the Salesforce CLI is installed. If not, [download it here](https://developer.salesforce.com/tools/sfdxcli). {% endstep %} {% step %} #### Authorize your org sfdx force:auth:web:login -a MyOrgAlias --instance-url {% endstep %} {% step %} #### Create a project (if needed) * sfdx force:project:create -n PermissionSetProject * cd PermissionSetProject Make sure, API version 63.0 or higher is specified in the sfdx-project.json. {% endstep %} {% step %} #### Place the XML file * Create a folder like force-app/main/default/permissionsets/ * Save your permission set XML file there with the .permissionset-meta.xml suffix: force-app/main/default/permissionsets/FundraisingBox\_Connector\_Standard\_Objects.permissionset-meta.xml ```xml true Account.BillingAddress true true Account.Fax true true Account.Phone true true Account.ShippingAddress true true Account.Website true true Campaign.Description true true Campaign.EndDate true true Campaign.ExpectedRevenue true true Campaign.IsActive true true Campaign.StartDate true true Campaign.Status true true Contact.AccountId true true Contact.Birthdate true true Contact.Email true true Contact.Fax true true Contact.HomePhone true true Contact.MailingAddress true true Contact.MobilePhone true true Contact.OtherAddress true true Contact.OtherPhone true true Contact.Phone true true Contact.Title true false true true true true true Account false true true true true true true Campaign false true true true true true true Contact false true true true true true true GiftCommitment false true true true true true true GiftCommitmentSchedule false true false false false true false GiftDesignation false true true true true true true GiftRefund false true true true true true true GiftTransaction false true true true true true true PaymentInstrument false true true true true true false PushTopic true false Account.Business_Account true PersonAccount.PersonAccount true ``` {% endstep %} {% step %} #### Deploy to your Org sf project deploy start --source-dir force-app/main/default/permissionsets/ --target-org MyOrgAlias {% endstep %} {% endstepper %}