Technical components

The main technical components of FinDock are present in every FinDock installation. FinDock installations can include extension packages which introduce components for specific payment processors ("payment extension") or a payment data source ("source connector"). These extensions are described in their respective articles.

Packages

The full FinDock solution consists of several packages. Most FinDock installations consist of at least:

• FinDock Core package
• ProcessingHub package
• A source connector package (optional)
• One or more payment extension packages

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

As a native Salesforce solution, FinDock uses a data model that is fully integrated with Salesforce using custom objects. The following illustration provides a simplified entity relationship diagram (ERD) of the main FinDock objects. Keep this model in mind when configuring and customizing FinDock.

Account and Contact

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.

Custom settings

Aside from the data objects, FinDock also contains a number of custom settings. These contain information needed by FinDock to function correctly. Although some settings can be viewed and even modified by users with sufficient access, doing so might prevent FinDock from functioning normally.

caution

Do not modify FinDock custom settings unless explicitly instructed to do so.

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 package configuration article(s).

Customizing FinDock objects

The FinDock data model and underlying business logic generally support customizing objects with custom fields. Where customization makes sense, we certainly encourage it. However, as with any customization, you should already proceed with care. Here we relate some important considerations for customizing FinDock objects.

General best practices for custom fields

Here are some general rules of thumb for customizing objects:

• Avoid customizations that block inserts and updates
  FinDock has extensive automatic processes for payment-related objects including Installment, Mandate, Payment, Recurring Payment. Don’t add customizations, such as required custom fields, that prevent inserting and updating.
• Be aware of existing dependencies
  Mandate Schedule, Payment Schedule and Transaction Set have the heaviest parent-child relationships, so be extra careful with rollups as they can have a big impact on performance
• Use required fields sparingly
  Add required customer fields with great care. We recommend not making custom fields required, but rather making them required on page layouts only. For more information, see Make a Custom Field required.
• Always consider the performance impact
  Validation rules, deduplication rules, Process Builder logic, trigger chains, etc. can significantly impact performance. Test thoroughly in sandboxes before adding to production.
• Handle NPSP object customizations with the same care
  FinDock is tightly integrated to NPSP when NPSP is used as the source of payment data. Customizations on Opportunity, Recurring Opportunity, etc. can have a major impact on FinDock performance.

Customizing payment-related objects

Customizations to payment-related objects should be done with great care given their central role in FinDock payment management. Custom fields are supported, and for certain objects, they can even be supplied through the Payment API. These objects include:

• Installment
• Mandate
• Payment
• Payment Profile
• Recurring Payment

In many cases, installments, mandates and payments are created (and modified) automatically by FinDock. This is why you should avoid required fields or validation that block these automated actions.

Custom fields on Installment, Recurring Payment (or recurring objects from other sources, such as Recurring Donation) are available through the Payment API. If you do add required custom fields to these objects, make sure they are correctly supplied to the Payment API.

Special considerations for Payment Profile

Be careful when defining deduplication rules on the Payment Profile object. FinDock does not support deduplication handling by Salesforce on this object. When creating new payment profiles, FinDock automatically deduplicates payment profiles connected to the same contact or account, but not across different contacts or accounts.

Customizing scheduling objects

Customizing schedule objects with custom fields and validation rules is supported. These objects include:

• Mandate Schedule
• Payment Schedule
• Recurring Mandate Schedule
• Recurring Payment Schedule

However, FinDock should at all times be able to update the status of the schedule. Customizations that disrupt this process might cause the schedule run to fail.

You can add custom validation to schedule objects with Salesforce rules, but the results are not part of the FinDock Data Quality component. The FinDock Data Quality component rules as such are not customizable.

Customizing inbound data objects

FinDock uses certain objects to capture inbound data for reconciliation purposes. These objects generally do not to be customized unless you have special incoming data practices, such as importing payment data files from 3rd party systems. The inbound data objects include:

• Inbound Report
• Transaction
• Transaction Set
• Transaction Sub Element

For the Transaction object, there are five fields, Custom 1 through Custom 5, that are available for customized purposes.

The Inbound Report object has over 70 fields, and we recommend making use of those existing fields before considering adding new custom fields. If you do create custom fields on Inbound Report, these fields are also available via the Payment API.

When it comes to Transaction Set, it might seem like a good case for custom roll-up summary fields. However, the Transaction Set object has many relationships, and we have seen roll-ups cause performance issues and processing errors.

tip

We strongly recommend using standard Salesforce reports instead of roll-ups to collect summary information from transaction sets.

caution

With roll-up summary fields on Transaction Set, you will likely run into locked row errors in Guided Matching when FinDock tries to process a Transaction Set record. If you encounter locked row errors, the roll-up summary field needs to be removed from the Transaction Set object and deleted from the recycle bin.

Customizing internal objects

FinDock has several objects that are used for tracking and other key functionality. These include Audit Trail, Log, Message and Payment Hub file. Customizations of these objects are generally not needed nor recommended.