When creating custom Guiding Matching rules, you need to choose first a specific Rule Types. The available Rule Types depend on the transaction field to which the new rule applies. The rule editor only limits the types depending on the selected field. The rules are either for matching or enrichment.
If you are using the Enhanced Online Experience with FinDock's Payment API v2, Guided Matching takes on a broader role in handling inbound payment data. For further information, please see Processing and reconciling online payments
Use this rule type to set the value of a transaction field to a constant value.
|Constant||The constant value for the transaction field|
Use this rule type to extract a value from a transaction field according to a regular expression. If the regular expression rule is used for a checkbox field, the checkbox field is checked if a match can be found. For example, let’s say you want to mark all transactions with the word ‘GIFT' in the payment reference. First, you create a ‘Has Gift’ checkbox custom field on Transaction, and then, using the Regular Expression rule type, create a rule with regular expression ‘GIFT’.
|Input Field||Field from which a value is extracted using a regular expression.|
|Regular Expression||A regular expression is a string that is used to match another string using a specific syntax. For further information, please refer to Oracle documentation. A nice tool and playground is RegExr.|
|Capturing Group||FinDock uses the REgEx outcome of the defined capturing group to store on the Transaction field. See this Salesforce developer doc|
|Example Input||Example text for the regular expression and capturing group. This is for testing and verifying that the regular expression behaves as expected.|
|Capturing Groups||All the resulting capturing groups given the specified regular expression and example input.|
|Result||The result given the calculated capturing groups and the specified capturing group.|
Use this rule type when you want to find a value by using a query of Salesforce data. Generated SOQL is logged in the Guided Matching Log field, and the query execution time is logged as queryTimeMillis. If Guided Matching fails, check these logs. Slow queries can lower matching performance. Values above 500 are too high. Please refer to standard Salesforce query performance best practices to solve issues in this area.
You should only query indexed fields. Querying a non-indexed field significantly lowers search performance. To index custom fields, under the general options for the field, set External ID to true.
The queries can be defined for matching multiple dynamic criteria on transaction fields, where a field value on the query object is matched to a field value on the transaction record. For example, you can match transactions against installments that have the same contact and the same amount.
For query rules on Payment Profile, the new Primary Identifier field should be used.
Criteria against a transaction field are only available if the comparison operator is ‘equals.’ Only the first and mandatory criterion (Account = Account in the example below) is included in the generated SOQL query. All ‘value’ criteria (Status != “Collected” in the example screenshot below) are included in the generated SOQL query. However, other ‘field’ criteria (Amount = Amount and Originating Campaign = Campaign in the example) are not included in the generated SOQL query. These are filtered out by looping through the query result set.
Make sure you use the most specific comparisons first. Salesforce has a per-transaction governor limit of 50,000 for total number of records retrieved by SOQL queries. The Guided Matching Query rule type explicitly checks if the query returns more records than allowed by the Salesforce limit with the addition of
LIMIT [Remaining Rows] to each generated query. If the number returned equals Remaining Rows, it is assumed that the governor limit has been exceeded, and the Transaction or Inbound Report records are set to Failed with a clear error message indicating the query limit was exceeded.
|Multiple Results Strategy||Strategy for what to do if the query returns more than one field. With Guided Review, the transaction record goes to guided review. Users are shown a table with all resulting records and need to select one of the records. Take First means the first record found is automatically selected. No Result sets the rule status to ‘Done, No Result’ and the next rule is processed.|
|Single Results Strategy||Strategy for what to do if the query returns only one field. Guided Review sets the transaction record to go to guided review. Users are shown a table with all resulting records and need to select one of the records. Take Result means select the record that was found.|
|Object to Query, Return Field, Where and Order by Fields||Together these fields are used to form a SOQL query. Note that for the where clause, SOQL is not case sensitive.|
|Filter||A filter for the Object to Query drop-down list, which can be very long. This value is not saved in any way.|
|Result Fields to Display||Only if Multiple Results Strategy ‘Guided Review’ is selected. Use this field to define how the table in guided review is rendered.|
Use this rule type to match Transactions or Inbound Reports to specific keywords. You can search for up to 500 keywords in a rule, but keep in mind the searching process is quite heavy. The searching stops on the first keyword found.
Before you can use Keyword Search rules, you need to have your keywords defined in Salesforce. You can do this with standard objects and fields or create a custom object for this purpose. The Keyword Search rule returns the selected field when matched, this could be a lookup to an object, a text field or any field. Below is an example rule that searches through keywords by ‘payment reference’ defined in the Keyword custom object and returns the Campaign object.
Keyword matching case insensitive.
|Keyword Object||Select the object (custom or standard) where your keywords are defined.|
|Filter||Use a filter to narrow the Keyword Object drop-down list, which can be very long. The filter value is not saved in any way.|
|Return Field||Defines which field on the Keyword Object contains the return value for a successful search. The Return Field value is added to the transaction field where the rule is used.|
|Where||Specifies the conditions for applying the Keyword Search rule. Those records that fulfill a specified condition. Define where the keywords are found in the Keyword Object, where they are located in the transaction record, and what the matching relationship should be. Use the plus button to add additional conditions.|
|Order by||Use Field and Sort Order to order the search results if needed.|
The Keyword Search rule based on regular expressions. That means your keywords are interpreted with regex logic. You can leverage this capability by, for example, adding regex constructs in your keyword values to cover a wider range or possibilities than exact one-to-one matches. For example, if you have run a campaign for supporting Syrian refugees and want to capture all possible transactions that have different spellings for “Syria,” you could have these in your keyword list:
Use this rule type to change how a string is present. For example, the raw string for a campaign code could look like ‘Save THE TIGer.’ You can use a normalize rule to change that to ‘savethetiger.’
|Case Strategy||Define how to handle capitalization. Select None to not normalize case. Select To Upper Case to change all characters to uppercase. Select To Lower Case to change all characters to lowercase|
|Whitespace Strategy||Define how to handle whitespace. Select None to ignore whitespace. Select Trim to remove whitespace at the start and end of the string. Select Remove All Whitespace to remove whitespace anywhere in the string.|
Use this rule type to extract a value from a Transaction or Inbound Report field according to the position of the value in the field. There are many payment files which are structured according to fixed positions, such as CODA and N43.
Extracted values are trimmed of excess filler spaces by default.
|Input Field||Field from which a value is extracted using fixed position parameters.|
|Line Starts With||A value will be extracted from the first line starting with this value. If this is left empty, extraction begins from the first line of the field.|
|Start Position||First position in the line of the value to be extracted. Note that the first position in a line is 1.|
|End Position||End position in the line of the value to be extracted. The characters between start and end position will contain the result of the extraction.|
|Only If Line Starts With, Start Position, End Position and Value||Many fixed length file formats have switches in the file. In order to make it easy to base logic on these switches, this rule includes an “Only if” refinement. The extraction rule is used only if Line Starts With, Start Position and End Position equals the Only If Value. If no “Only If” refinement is provided, the rule will be processed if the entry criteria are met.|
If you know certain fields may need something from the user who conducting the review, use this rule type to define the manual actions for the reviewer.
|Guided Review Type||Defines the review action. Salesforce field: the Salesforce field is shown to the user in the Guided Review component in edit mode. The user can set the value. Search (only for reference type fields): guided review asks the user for a search query after which a SOSL query is performed on all fields to find related records. Users can select one of the results, after which guided matching continues. Combined Contact and Account Search (only on Contact): this is similar to Search, except that it allows searching Contact and Account at the same time.|
|Result Fields to Display||Specify which fields to display in the search results of the guided review component; only relevant for Search, Combined Contact and Account Search.|
|Prefill Search Box with Transaction Field||Select a transaction field to prefill the search box and automatically do the first search based on the field value; only relevant for Search, Combined Contact and Account Search.|
|Max Number of Results||Specify how many results are displayed in the search results (range 1-50); only relevant for Search, Combined Contact and Account Search.|
|User Guidance||Special guidance for the guided review that is displayed to the reviewer.|
|Show “Skip & Continue” Button||Select this option to allow the user to just skip the current guided review rule and proceed to the next rule.|
Use this rule type to create a Record, Contact, Payment Profile or Installment. For Contact, Payment Profile and Installment, mapping is automatic wherever possible to ensure data is created in a way that FinDock supports. The auto-mapping is described clearly in the rule setup section. For the Create Payment Profile rule, you can also map the correct record type.
Enforce uniqueness should be enabled (FinDock general settings) if you use a create Payment Profile rule. The Payment Profile enforce setting is enabled by default for FinDock installations after the June 2020 release. You can use a create rule for Payment Profile without enabling enforce uniqueness. However, processing this rule may lead to duplicate records in some cases. In the example below, a record is created based on information in the processed file.
|Mapping||Each field of the created object can be mapped. A field can be either mapped to a constant value or to a Transaction field.|
|Upsert Field||Under advanced settings, select this option if you want the rule to use an upsert operation, instead of insert, using the selected field as key. Upserting ensures there is no chance of duplicate records being created. A deduplication approach using a query rule to first find existing records and then only create if not found catches most duplication scenarios. However, this approach cannot 100% guarantee no duplications because of the parallel processing characteristics of Guided Matching.|
Use this rule type to update any object. This rule can be added to any lookup or master-detail field.
The rule will be skipped if no record is related to the Transaction or Inbound Report record. In all other cases, it will update the related record according to the mapping you have defined.
|Mapping||Each field of the related object can be mapped. A field can be either mapped to a constant value (mapping type: Value) or to a Transaction or Inbound Report field (Mapping type: Field). If the “Only If Blank” checkbox is selected, the field will only be updated if does not already have a value.|
The Update Campaign Member rule is a special update case because Salesforce does not allow lookups to Campaign Member. The Update Campaign Member rule instead acts on the text field “Campaign Member Id” which comes pre-shipped from FinDock on Transaction and Inbound Report.
This rule is always included in the rule exception plan as the last step. It processes the attached installment. The processing steps are as follows:
- If the installment has been processed already before (cpm__Guided_Matching_Installment_Processed = true), the rule is skipped. If an installment is attached, the transaction status is set to ‘Matched.’ If not, it is set to ‘No Match.’
- If the transaction has already been matched by ProcessingHub (cpm__Matched_By_ProcessingHub__c = true), the transaction is set to ‘Matched’ without further consideration.
- If the transaction has no installment linked, the transaction record is set to ‘No Match.’
- In all other cases, the following decision table is applied.
|Transaction Debit / Credit||Installment Receivable / Payable||Other||Transaction Status after Processing||Installment Status after Processing||Installment Amount Open after Processing||Payments after Processing|
|Credit||Receivable||Transaction Amount = Installment Amount Open||Matched||Collected||0||New payment with Transaction Amount|
|Credit||Receivable||Transaction Amount < Installment Amount Open||Matched||Partially Paid||Installment Amount Open – Transaction Amount||New payment with Transaction Amount|
|Credit||Receivable||Transaction Amount > Installment Amount Open||Matched||Collected||Installment Amount Open – Transaction Amount||New payment with Transaction Amount|
|Debit||Payable||Transaction Amount = Installment Amount Open||Matched||Paid||0||New payment with -1 * Transaction Amount|
|Debit||Payable||Transaction Amount < Installment Amount Open||Failed||Not changed||Not changed||Not changed|
|Debit||Receivable||Transaction Amount = Installment Amount & Installment Status = Collected & Installment Amount Open = 0||Matched||Reversed||Installment Amount||New payment with -1 * Transaction Amount|
|Debit||Receivable||Else||Failed||Not changed||Not changed|
|Credit||Payable||Installment Amount Open after processing <= 0||Matched||Paid||Installment Amount Open + Transaction Amount||New payment with Transaction Amount|
|Credit||Payable||0 < Installment Amount Open after processing < Installment Amount||Matched||Partially Paid||Installment Amount Open + Transaction Amount||New payment with Transaction Amount|
|inCredit||Payable||Installment Amount Open after processing >= Installment Amount||Matched||Outstanding||Installment Amount Open + Transaction Amount||New payment with Transaction Amount|
If you have NPSP as a source package, the Manage Source rule creates an NPSP Opportunity if no existing Installment (and thus Opportunity) was found. To create the Opportunity FinDock uses the mapping as defined in the NPSP Opportunity Installment mapper.
The Manage Source Rule Type is included in all managed rule sets and can not be added through the Guided Matching setup.