Skip to main content

Starting a project

This page outlines all the main topics and actions for rolling out FinDock for a Salesforce org. We’ve included links to relevant Knowledge Base articles, as well as Salesforce sources where relevant.

A quick overview of FinDock​

FinDock is a Customer Payment Management (CPM) solution built 100% native for Salesforce. You can connect Payment Service Providers (PSPs) and banks directly to FinDock and use a different payment processor for each payment method, currency and region. FinDock itself can also process payments from any source. Use the payment schemes within FinDock or collect single and recurring payments based on custom objects, invoices, payment schemes, other AppExchange solutions, or even schemes from external systems.

Common use cases​

A few of the use cases where FinDock can be used to meet the requirements are:

  • Collect funds through direct debit (either BACS or SEPA) from customers based on invoices stored in Salesforce
  • Process online transactions through a PSP such as Worldpay and store all payment data directly in Salesforce
  • Provide follow-up opportunities for missed or failed payments based on pledges made in the Salesforce Nonprofit Success Pack, including offering alternative payment methods such as PayPal to close reversed direct debit transactions

This list is just to give you an idea of how FinDock could be used. You can combine many more elements of FinDock into different scenarios to fit your specific payment management requirements.

Lightning vs. Classic​

FinDock is built with the Salesforce Lightning interface in mind. However, all main functionality works in both Lightning and the Classic interface. Some extension packages might contain Lightning components that are not available in the Classic interface.

FinDock's main elements​

A FinDock configuration consists of four main elements: (1) FinDock Core, (2) ProcessingHub, (3) one or more source connectors and (4) one or more payment extensions. For information about the FinDock data model, see Technical components.

FinDock Core & ProcessingHub​

FinDock includes all the necessary logic to handle payments, register cash flow, etc. It orchestrates how and when different extension packages are used. The Core package (also known as PaymentHub in older instances) forms the essential backbone of the entire solution. ProcessingHub refers to the engine which plays a critical role in:

  • Bulk collection file creation (such as direct debit files)
  • Collection file delivery (such as to a PSP or within Salesforce)
  • Bank statement file recognition and parsing
  • Bank statement transaction matching

Source connectors​

Source connectors provide the translation between a source package and FinDock. For instance, if you use FinDock with the Salesforce Nonprofit Success Pack, you need to install the FinDock for NPSP source connector.

Payment extensions​

Payment Extensions connect PSPs, or in some cases payment collection schemes such as Bacs (United Kingdom) or SEPA (Europe), to FinDock. Payment Extensions contain payment methods that are available in FinDock once the extension is activated. An example of a payment extension is Worldpay. This extension uses a credit card payment method and allows you to process one-time and recurring credit card transactions through the payment service provider Worldpay.

Implementing FinDock​

If the FinDock implementation coincides with a broader Salesforce implementation, make sure to plan and align tasks with the project responsible for the Salesforce roll out. The following is a basic outline of the steps for a new FinDock implementation.

Preparation​

Before starting your implementation, make sure to get everyone aligned on the required steps and actions. We recommend that you clearly define your project methodology, success criteria and timeline. We also recommend creating a communication plan that keeps key external parties (such as FinDock) in the loop so that changes or potential issues can be resolved quickly. Good governance helps prevent issues and unexpected behavior in the long run.

Especially if the Salesforce org plays a pivotal role in the customer’s cash flow and donor registration, you need a comprehensive governance plan covering support, maintenance and future development. Ideally the governance framework is defined with input from the customer as well as external parties, including FinDock.

Installing FinDock​

The customer’s contract includes a list of the FinDock packages to be installed. A FinDock configuration consists of multiple packages which can be installed using installer.findock.com in your production and/or sandbox environments. FinDock installation, configuration, target creation, page layout modifications, approval processes and other configuration items are done by the customer together with their implementation partner.

There are six phases of installation and configuration, as described in the following articles:

  1. Installing FinDock packages
  2. Permissions.
  3. Configuring FinDock Core
  4. Configuring Webhub and Notification Gateway
  5. Configuring ProcessingHub
  6. Activating source connectors
  7. Activating payment extensions

Integrating systems​

In many cases, the FinDock and Salesforce implementation is part of a larger IT landscape, with dependencies and integrations between different systems. For the FinDock implementation, these integrations typically include:

  • Website or mobile app integration for payments and donations
  • Accounting system integration for exporting the cash flow registration

For the website or mobile app integration, FinDock provides a Payment API. Using this API requires some configuration on the Salesforce side, as well as by the internal or external web/app developer.

For more information on the FinDock Payment API, please see:

To use the Payment API, a connection with FinDock WebHub is required. Please see:

Planning data migration​

Most implementation projects include some form of data migration. We recommend you address at least the following:

  • How much data are you going to migrate? Make sure to discuss with the Salesforce Account Executive how much data will be migrated and calculate the Salesforce Data Storage usage accordingly.
  • How are you going to register past payments? If no further processing of past transactions is needed, consider just storing them. For example, with Salesforce NPSP, you can move them to Opportunities rather than Opportunities with Installments. If FinDock may need process past transactions, such as Reversals for Direct Debits or Gift Aid, make sure to create Installments for migrated payment records.
  • Test migrated data. Make sure you can run processes on the migrated data. For example, test payment collection based on the migrated records. This ensures you have migrated the data not only to the right objects, but also the correct fields.
  • Take your time and test often. Data migrations are notoriously difficult. Start data migration as early as possible in the project and give yourself a large time buffer. Create the mappings, plan multiple test migrations, etc. This pays off in the later stages of the project in terms of run time performance, error mitigation and data quality.

More information on data migration and bulk data uploads, please see Migrating payment data.

Configuring communications​

Every organization has some form of communications concerning payments. This may include, for example:

  • Direct Debit pre-notifications
  • Confirmation of changes (bank account changes, collection date changes, etc.)
  • Thank-you messages for new customers/donors
  • Summary reports of payments and/or donations

FinDock provides the information required for these kinds of communications, but includes no out-of-the-box templates as the formulations differ greatly from payment method to payment method and country to country. In some payment schemes, communication content needs to be approved by the bank or payment service provider. For example, in the UK all communication relating to direct debit, including confirmation emails, need to be approved by the bank. Make sure to check if this is the case for your customer and plan communication development accordingly.

Handling unpaid payments​

Every organization faces unpaid, overdue, failed or reversed payments at some point. based on these transactions. The right message at the right time can significantly speed up payment of unpaid or overdue invoices or pledges. FinDock provides the necessary data to initiate appropriate follow-up actions and journeys, such as:

  • Retry journeys for Reversed Direct Debits: these can be based on the reason code for the reversal, such as insufficient funds.
  • Follow-up query on Failed Direct Debits: failure might be because, for example, the bank account is incorrect, the organization was mistakenly blacklisted, or the donor/customer forgot to add the organization to a direct debit white list. Follow-up may also be needed for unpaid bank transfers and other accounts receivable not actively collected, or overdue invoices payable via bank transfer.
  • Follow-up on failed online donations: this typically happens with ‘abandoned cart’ processes for online transactions.

The Salesforce ecosystem provides a variety of tools to help you implement these flows, from mail merge tools for physical mailings, to online customer journey management tools such as Marketing Cloud and Pardot.

Testing and validating implementation​

Before go-live, perform extensive testing on your entire setup to ensure the business processes run smoothly and the goals of the implementation are being met. Testing should be an integral part of the entire implementation process.

The final testing round before go-live brings all the (independent) configurations together and tests the implementation as a whole. The purpose of testing is to validate the implementation and find gaps or deficiencies. Make sure to plan for development time to fix issues that may be discovered so that the go-live date can be met. Testing FinDock in any phase is best done on a full-copy sandbox with exactly the same data and settings as the production org. If you don’t have a full-copy sandbox, inquire with the Salesforce Account Executive about the possibilities.

Test scripts & scenarios​

We recommend documenting detailed testing scenarios and validating them with the organization to ensure you cover all aspects of the business processes and day-to-day activities. A typical test scenario should include:

  • A high level overview of the process/functionality being tested, together with a high process level flow.
  • Step-by-step test flow that includes:
    • Context (language, currency, configuration dependencies, etc.)
    • Input conditions (such as the data entered)
    • Sequential test actions
    • Expected outcome
  • Success & failure criteria

We recommend your test scenarios cover the following:

Scale tests If the organization performs large payment collection runs, make sure to test for scale. Perform test runs that exceed the largest predicted collection run to ensure the Salesforce org is configured to handle the high volume of record update and/or create actions performed by FinDock.

End-to-end tests Many individual aspects of the configuration are tested as stand-alone functions during implementation. It is important to test end-to-end processes before go-live. For instance, a customer or donor lifecycle test should cover everything from initial sign-up to upgrades and downgrades, renewal, and end-of-donating processes to ensure every aspect of these individual functions work together seamlessly.

Penny tests Penny tests are tests with actual cash flow. For instance, these can be direct debit runs for a few individuals with low amounts (hence the name, ‘penny test’). These tests are essential to confirm cash flow works as expected. Perform penny tests for every payment method configured in the production org. These tests might conflict with other on-going activities, such as direct debit reporting which can’t distinguish between penny tests and real-world production transactions. In such cases, together with the customer organization, contact the bank or payment service provider to discuss how the tests can be run without disrupting normal business.

Go-live preparation​

When all configurations are done, it is time to make the final preparation for go-live. At this point, make sure everybody involved in the project is up to speed on the planned go-live arrangements. This includes informing external parties that go-live preparation is now underway and remind them of the planned go-live date. While many configurations can be deployed from your sandboxes to the production org, some items require manual work in the production org. These include:

  1. FinDock packages and versions: check that your production org has all the required packages with the same versions as in your sandbox org. Also make sure the packages and payment methods are activated on your FinDock Setup page in the production org and verify if the packages are correctly configured. Make sure IsTest is disabled when you use any Payment Service Provider.
  2. FinDock general settings: make sure the configuration is complete in the production org prior to go-live. This includes assigning permissions.
  3. Target configurations: target configurations can be deployed between Salesforce orgs. All information is stored in the cpm__target__property__c object. However manually creating the targets in production is usually the easiest way to get the right targets in production. Please verify that the target configuration in the production org is correct and create or adjust your targets if needed. When the targets are correctly configured, use the Deploy Config button to deploy the targets throughout the whole Salesforce org.
  4. Guided Matching: if you use Guided Matching and have created or adjusted any custom Guided Matching rules, you can copy those rules by copying the data in the cpm__guided_matching_setup__c object.
  5. Page-layout assignments: if you have updated any page-layout assignments, make sure you apply these on the production org as well.
  6. Sanity check: before go-live you should make sure all payment flows and integrations are tested (see Penny Tests). More specifically you could think of a penny test for:
    • Direct Debit (file creation)
    • Automated upload of bank reports and bank statement files
    • API integration with Giving Pages or your custom webform, including receiving the notifications from your Payment Service Provider
    • Run a Payment Schedule for for every Payment Processor you use
  7. Initial Sync The first process that runs on the ProcessingHub (for example running a Payment Schedule for Direct Debits or uploading a bank statement file) requires an initial sync. All FinDock relevant data in your Salesforce environment needs to be synchronized to the ProcessingHub. Depending on the number of records the initial sync could take significant time. You can save time during a crucial go-live day, by running the initial sync before go-live. For example by uploading an empty bankstatement file or run a small Direct Debit Payment Schedule directly after the majority of the data is migrated. This will trigger the initial sync. When that is finished, you can migrate the remainder of the data as close as possible to your go-live date. This ensures the first process after go-live that requires ProcessingHub will not take long, as it only needs to synchronise the data that has changed since the initial sync.
  8. Other planned steps: complete any other planned post-deployment or pre-go-live actions as decided by the implementation project team.

Further guidance​

Following the best practices and tips outlined in this article helps your implementation and subsequent go-live to be successful. However, if you would like further guidance and more involvement of FinDock especially at the start of your implementation project, FinDock offers an implementation kick-off workshop. If you’d like to know more, please contact sales@findock.com.