Skip to main content

Technical components

The main technical components of FinDock Core are present in every FinDock installation. Some installations might include extension packages with separate components. These components are described in their respective articles.


The full FinDock solution consists of several packages, each containing specific logic for their task. Most FinDock installations consist of at least:

  • FinDock Core package
  • ProcessingHub package
  • A source connector package
  • A payment extension package

All FinDock packages are managed packages that have passed the Salesforce security review. This means that the objects and code contained within these packages do not count against the custom object or apex limit in your org. However, other limits on API calls, data and file storage still apply!

FinDock data model#

The FinDock core objects are related as illustrated in the follow Entity Relationship Diagram (ERD). It is important to keep this model in mind when configuring and customizing FinDock.

FinDock ERD

FinDock contains several objects itself, and uses the Salesforce standard Account and Contact objects.


Some extension packages might contain additional fields or objects.

Accounts and contacts#

These are standard Salesforce objects you are most likely already familiar with. FinDock does not modify these objects. However, FinDock is equipped to handle any custom field you might create or install through a third-party package. For more information about contacts and accounts, see the Trailhead module Accounts & Contacts.


API name: cpm__Installment__c

The Installment object might be the most important object in FinDock. It represents a single amount receivable. It always represents that particular amount receivable, meaning that you can at any time track if this amount was paid and when. In the case of a reversal or refund, you can track the amount back to the exact Installment that is involved. Read more.


API name: cpm__Payment__c

The payment object mainly represents cash flow. Every time money changes hands (collection, refund, reversal), a Payment record is created to reflect this transaction. Each Payment is linked to an Installment. One Installment, on the other hand, can have multiple Payments. Read more.

Payment Profile#

API name: cpm__Payment_Profile__c

The Payment Profile object contains card or bank information. A contact or account can have one or more Payment Profiles containing credit card tokens, IBANs, bank account and sort code combinations, etc. Read more.


API name: cpm__Mandate__c

The Mandate object contains the authorization given by a donor or customer to collect funds from their account. The most common use cases for the Mandate object are the SEPA Direct Debit Mandate and the BACS Direct Debit Instruction. In these cases, a correctly registered mandate allows you to perform direct debit collections on the IBAN or bank account specified in the Payment Profile. Read more.

Payment Schedule#

API name: cpm__Payment_Schedule__c

The Payment Schedule object represents a single bulk payment collection run for a specific source and payment method. Read more.

Recurring Payment#

API name: cpm__Recurring_Payment__c

The Recurring Payment object is only used if FinDock is configured as its own source. The Recurring Payment object allows you to define a certain amount to be receivable each month, quarter, twice a year or yearly, as well as define the required payment method and processor. Read more.

Transaction Set and Transaction#

API name: cpm__Transaction_Set__c API name: cpm__Transaction__c

The Transaction Set and its child Transactions are linked through a Master-Detail relationship and are used to capture bank statement imports in FinDock. Every transaction on a bank account becomes a single Transaction record linked to a Transaction Set that groups all the records of that import. Read more.

Audit Trail#

API name: cpm__Audit_Trail__c The Audit Trail object is used to store audit records listed in the Audit Trail tab under FinDock Setup. Read more.


API name: cpm__Log__c

The Logs object is used to capture system log messages submitted by various components of the FinDock solution. Read more.


API name: cpm__Message__c

The message object is used to add actions to a queue for asynchronous processing. Read more.

Inbound Report#

API name: cpm__Inbound_Report__c

The inbound report contains reporting related to bulk collection results and mandates for specific payment schemes. Read more.

Custom settings#

Aside from the data objects, FinDock also contains a number of Custom setting objects. These records contain information needed by FinDock to function correctly. Although these settings are not protected and can potentially be viewed and even modified by administrators or users with sufficient access, doing so might cause your FinDock installation to break!


Never change these settings directly on the Custom Setting object. Always use the proper page or action to modify these settings.

Custom Remote Site Setting#

Contains remote site settings that need to be added to the Salesforce Remote Site Settings for certain functionality to work, for example the ProcessingEngine URL. These are added when FinDock packages are activated.



Iban Validation#

Contains regex expressions to validate the IBAN pattern for each country. These records are added or modified on installation or update of the FinDock Core package.

FinDock Settings#

Contains the main settings for FinDock, these are set through the FinDock setup page.

Payment Method#

Registers activated payment methods in FinDock. These records are modified by activating or deactivating payment methods in payment extension packages.

Payment Service Provider#


Process Setting#




Setup Record#

Contains the setup registration of installment FinDock extension packages. There records are modified by installing, updating or uninstalling FinDock extension packages.

Source Setting#



Contains a local copy of the targets defined in ProcessingHub.

Apex batch and schedule classes#

FinDock contains a number of schedule and batch classes that perform various tasks. Configuration for each of these classes is discussed in the relevant function are configuration article(s).