Release Notes - November '25

Important Dates:

• Release to sandboxes: November 2, 2025
• Release webinar: November 7, 2025
• Release to production: November 30, 2025

Classic permission sets reach end-of-life

As announced in our May '25 release, the FinDock classic permission sets are now officially retired with the November '25 release. The classic permission sets in existing installations become unmanaged permission sets that you can keep or unassign. New FinDock installations from this release onwards no longer include the classic permission sets. If you have not already done so, we recommend migrating to FinDock permission set groups.

Salesforce Security update: Guidance for connected apps

The Salesforce security updates rolled out in September 2025 require all connected apps to be explicitly installed in an org. The connected app installation needs to be carried out by a system administrator or an admin user with the Approve Uninstalled Connected Apps user permission.

The connected app installation requirement impacts the following FinDock apps:

• FinDock Installer
• FinDock MIDAS
• ProcessingHub
• WebHub

To help customers with this new requirement, we embedded new guidance in the FinDock Installer app and FinDock Setup. We also updated our docs to cover the connected app procedures in full detail.

NEW PILOT: Collection Amount Open

We are introducing a new collection logic to allow customers to collect payments based on the Amount Open field of the given Installment record. Prior to this release, FinDock only used the Amount field of the Installment record for collections through payment schedules. This new logic allows payment schedule collections to reflect the latest state of an installment. For instance, if the installment is partially paid, the next collection is only for the remainder instead of the full original amount.

The new logic will be piloted first with self-managed SEPA Direct Debit using FinDock as a native processor. Pilot customers who want to switch to the new collection logic can do so using a new advanced setting that is activated in the org for pilot testing.

If you would like to participate in piloting the new payment extension, please contact FinDock Support.

Payment schedule counters for Amount Open

We have updated the counters logic on payment schedules to support the new Amount Open collection option. When the Collect Amount Open setting is enabled, the counters use the Amount Open field value from the installments linked to the payment schedule. If the value is 0, the counter uses the Amount field from the Payment record dated according to the schedule collection date. In all other cases, the counter falls back to Amount on Installment for the calculation (as when the option is disabled).

Collection logic for Amount Open

As part of the Amount Open collection logic, we have added new logging to ProcessingHub Manager. There you will now see what was collected for an installment in a given payment schedule run, e.g.

Amount: 100 is used for this installment.

Amount Open: 50 is used for this installment.

NEW: Salesforce Bulk API 2.0

We are happy to announce that FinDock is fully integrated with Salesforce Bulk API 2.0. All new installations use new and improved API. With the new API, FinDock also simplifies ProcessingHub configuration by eliminating the need to optimize performance through batch sizes and concurrency modes.

Existing FinDock installations are not changed with this release. Your orgs continue to use Bulk API.

Guided Matching

Minor UI adjustments for Bank Feed and Guided Matching

We have made a couple of minor UI-related adjustments for Bank Feed and Guided Matching to improve the user experience.

• Bank Feed: if there is no active Bank Feed license for the org, users will no longer see callouts about expired bank account connections.
• Guided Review: we fixed some alignments in the Guide Review layout for batch matching

Guided Matching rule execution texts

Issue: The Process Installment step in the rule execution component always showed “Multiple Installments,” even if the matching context was for a single installment.

Solution: The rule execution component now only shows “Multiple Installments” if the Process Installment rule is handling multi-installment matching. For single installment matching, the text “Single Installment” is shown.

Matching of multiple pending transactions with the same IBAN

Issue: In the September '25 release, we introduced a Transaction matching fix that could in certain scenarios prevent Guided Matching from finishing processing multiple Transaction records for the same IBAN and with status Pending. This resulted in multiple Pending transactions in the transaction set, and matching could not be triggered again with the "Start Guided Matching" option for the set.

Solution: The issue arises when Pending records are processed in parallel, creating a state in Guided Matching that blocks the next matching job from starting. To avoid this situation, we have introduced additional logic that ensures Guided Matching can finish processing a Pending transaction before picking up the next Pending transaction with the same IBAN.

Core

Queueable framework enhancements

As part of our ongoing efforts to make FinDock more robust, we identified some queries logic and Apex classes that could be improved. We were able to deprecate an Apex class due to improvements Salesforce has made in SOQL, as well as update another class to use a more refined service. We also optimized some query logic to ensure queries are only executed when absolutely necessary.

Improved queueable framework general logging

To make troubleshooting the queueable framework easier, we’ve added new package-specific logging to catch possible exceptions thrown by the framework. This update impacts logging for the following packages: Authrorize.Net, Core, Fundraising, Gift Aid, GoCardless, Mollie, ProcessingHub and Vipps.

We have also added new information to the FinDock Log object (cpm__Log__c) that will help track the lifecycle of the queued jobs. In addition, we refactored some existing logging patterns to optimize data used and clarify.

Enhanced prevention of duplication collection

We have further enhanced our queueable framework in this release to make it more robust against duplicate payment collections. The new safeguard is a blocking mechanism deep in the framework logic.

The blocking logic prevents, without exception, parallel processes that end up in an unexpected racing condition from changing installment states. Such conditions not already caught by FinDock’s existing safeguards are extremely rare. They are, however, theoretically possible, so we’ve added this new safeguard to cover all possible racing conditions.

Salesforce Workflow Rules removed

Salesforce is retiring Workflow Rules (and Process Builder) at the end of 2025. In our September '25 release, we disabled the three remaining workflow rules used for mandate-related actions and replaced them with Apex triggers. As a final step in this release, we have removed those workflows from the codebase so they are not part of new installations from November '25 onwards. With this change, existing customers can also remove these workflows from their orgs if desired.

FinDock logging of Guest User events

Issue: FinDock logs (cpm__Log__c) triggered by a Guest User, such as in an Experience Cloud flow integrated to FinDock, cannot be processed, throwing the system error “Guest User cannot be owners.”

Solution: The issue is caused by the ownerId field on the Log record. FinDock sets the owner according to whichever user triggered the platform event. However, the ownerId cannot be a Guest User. To resolve this logging issue when the user context is Guest User, we have replaced ownerId with two new fields on the Log object:

• Logged By (cpm__Logged_By__c) - new lookup field
• Logged By (cpm__Logged_By_User_Link__c) - new formula field used to show a link to the user in the log record List view and Layout. The value is taken from Logged By after this release. For existing log records, the value is taken from ownerId.

FinDock Setup page load performance improvement

Issue: With many payment processors and methods activated in an org, the Processing setup page may not load, and refreshing results in internal server errors. This is an unlikely scenario in real orgs, but it was caught in our internal stress test orgs where 60+ methods are simultaneously active.

Solution: The issue was caused by the underlying queries used to build the page. We’ve optimized these now to be more robust so they can handle very large numbers of active processors and methods.

Permission set update

For the new Amount Open collection feature, we have added an Apex class to the FinDock Core Setup permissions so pilot (and future beta testing) customers can access the feature toggle.

Payment Schedule stats in multi-currency orgs

Issue: When multi-currency is enabled, the counters on the stats component displayed incorrect totals for the payment schedule.

Solution: The stats component now checks the currency of all installments linked to the given payment schedule. If multiple currencies are detected, the most common currency among the installments is used to calculate the stats. Values in other currencies are converted to that most common currency as part of the calculations.

Manual schedule generation from Recurring Payment Schedule

Issue: When a Recurring Payment Schedule record is created without using FinDock’s automation (auto-create), the Generated Payment Schedules Preview component always shows Payment Schedules are already generated and can't be run again from this Recurring Payment Schedule. This blocks manually generating payment schedules in advance for the recurring payment schedule.

Solution: The issue was caused by an error in how schedules are identified and selected for the preview component. This has now been fixed so that the component displays correctly and schedules can be manually generated in advance as expected.

Further security enhancements

As a continuation of the July '25 and September '25 security enhancements, in this release we introduce further enforcement measures related to Salesforce FLS and CRUD permissions.

PaymentHub File layout with record details

Issue: In the September '25 release, we updated the Lightning page for the PaymentHub File object which removed the record details. This created additional customization work for customers who customize and use the record details.

Solution: We re-added the Details tab to the default Lightning page for PaymentHub File, along with a Related tab, and added a file details component.

Permissions export for FinDock analytics

Issue: With the Sept. 25 release, we modified the data export for analyzing FinDock permission set usage to gather information on the classic permission sets that are reaching end-of-life soon. However, the export was overly broad and pulled in unneeded permissions-related org data. No customer or personal information was exported.

Solution: We improved sync by narrowing the scope with better filtering. The already synced data was deleted and syncing restarted after the improvement was rolled out. In addition to filtering, we further optimized Bulk API usage to reduce batch consumption.

ProcessingHub

Enhanced logic for preventing blocked processes

Issue: In several scenarios, payment schedule processes can be blocked by the error Collection date can't be empty. This occurs when ProcessingHub is generating a Payment record for an installment that has already been changed to closed status, such as Collected, through some other action or process.

Solution: We changed the ProcessingHub logic to only generate a Payment record if the installment has a Last Collection Date value. If that field is empty, the installment is skipped. This ensures all created Payment records have a valid Collection Date and prevents blocked ProcessingHub processes.

Enhanced data syncing

For many FinDock customers, data syncing between ProcessingHub and Salesforce is completed before you even realize it started. However, the sync can be noticeably slow in orgs with several hundred thousands, or even millions of records.

To address the performance needs of large orgs, we refactored how queries are executed in ProcessingHub. All orgs get a performance boost from the new syncing logic, but the biggest improvement will be seen in orgs with very large record counts.

Fundraising (NPC, EDU)

Installment status mapping for Written-off

Issue: If the status of a Gift Transaction record changes to Written-Off, the status of the linked Installment record is not updated.

Solution: The installment status was not updated because FinDock for Fundraising did not have a status mapping for Written-Off. This status has now been added to the connector Status Mapping with a default mapping to Cancelled on Installment. The status sync is bi-directional, however, note that changing the Installment status to Cancelled does not change the Gift Transaction status to Canceled (primary mapping) if the Gift Transaction status is already Written-Off.

FinDock for Fundraising flows updated

We’ve updated the FinDock for Fundraising flows on FinDock Labs so they are fully compatible with the Salesforce Winter ‘26 release.

Buckaroo

Queueable framework support

To support a new customer use case for high volume SEPA Direct Debit collection runs in excess of 100,000 installments, we have re-engineered the Buckaroo extension to use our queueable framework. The framework implementation supports bulkified processing for all payment methods available in the Buckaroo extension.

Handling update for HTTP Status 200 response

Issue: Installments in a payment schedule run that receive an HTTP Status 200 response from Buckaroo with an error in the body are not properly handled. The installment status is not updated.

Solution: The error in the 200 response is: A technical error occurred. The page cannot be displayed. When this occurs, FinDock now captures the error and sets the impacted installment status to Failed.

Norway

Bulk KID generation with Payment Type

Issue: When generating values for Giro (KID) payments through the Payment Request Generator, the generated references did not take into consideration the optional Payment Type of the KID configuration of the FinDock for Norway setup.

Solution: The Payment Request Generator did not check if Payment Type is enabled or not. This has now been fixed so that the optional KID parameter is included when enabled. In addition, we reviewed and unified all KID generation contexts to ensure the generation logic is consistent regarding Customer ID generation or reuse, as well as Payment Type generation or reuse (as part of an existing Customer ID).

Stripe

Support for one-time and recurring Pre-Authorized Debit (PAD)

The FinDock integration with Stipe now supports Pre-Authorized Debit, a direct debit payment method used in Canada to collect payments in Canadian dollars (CAD) and US dollars (USD). Payers can initiate both one-time and recurring PAD payments through online channels including Giving Pages, PayLinks, and custom Payment API integrations.

PAD payments require payer bank account validation. FinDock supports both instant and micro-deposit verification methods. As with ACH direct debit, FinDock does not actively manage mandates. They are managed by Stripe, and Mandate records in Salesforce are created and updated based on Stripe notifications to FinDock.

Worldpay

New recurring card payment through MOTO

Issue: When using the FinDock Payments component to set up a recurring card payment while 0-auth is enabled, WorldPay returns an error indicating the CVC is not valid.

Solution: The issue was caused by a bug in the callout from FinDock to Worldpay. This has now been resolved so that recurring card payments can be set up as expected with 0-auth enabled.

Reuse existing card for MOTO

Issue: The “Reuse existing payment method” option for the FinDock Payments component results in an error about a missing parameter. This prevents the MOTO payment from being completed.

Solution: The issue was caused by an incorrect parameter used in the callout from FinDock to Worldpay. This has now been fixed so that the reuse payment method option works as expected.

General Maintenance

Salesforce API version bumping

Salesforce platform API versions in all FinDock packages for Apex classes and triggers, Lightning Web Components, etc. have been updated to version 65.0. This update ensures FinDock is fully compatible with the Salesforce Winter '26 release.

Heroku app maintenance

This release includes version upgrades for software components used in FinDock apps on Heroku. These updates apply to ProcessingHub, WebHub, Notification Gateway, FinDock MIDAS, as well as FinDock access management frameworks.

MIDAS maintenance

As part of our standard maintenance procedures, we analyzed endpoints used by FinDock MIDAS, our installation and configuration and deployment app on Heroku, and deprecated one endpoint that is no longer in use.