> For the complete documentation index, see [llms.txt](https://solutions.fundraisingbox.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://solutions.fundraisingbox.com/knowledge-base/duplicate-management.md). # 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://solutions.fundraisingbox.com/knowledge-base/duplicate-management.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.