› Capture › Extraction groups › Document type › Properties of a document type › Field validation › Post validation handling

Post validation handling

You can plug your implementation into the process of TotalAgility validation, and using TotalAgility SDK, implement custom validation based on actual capture data regardless of the component (Capture Client, Transformation Server, or Core Worker) who runs the validation.

Custom validation configuration

You can enable custom validation for a document type in TotalAgility Designer.

  1. Navigate to Capture > Extraction groups.

  2. Select the required extraction group > document type.

  3. On the Field validation tab, select Post validation handling. (Default: Clear – This means that the post validation process map is not executed even if it exists.)

  4. On the Process map list, select a process map to assign as a post validation handler.

Post validation handler

The post validation handler process map must be synchronous and must have the following set of input variables:

  • Document ID: String

  • List of field names: Dynamic complex variable

The dynamic complex variable must have exactly four columns as shown below.

Name

Type

Description of columns for table field case

Description of columns for non-table field case

FieldId

string

The ID of the table field.

The ID of the field.

Name

string

Name of the column.

Name of the field.

TableRow

short

Corresponding indexes of specific cells within the table.

For full table validation, indexes are -1.

Set to -1

TableColumn

short

TotalAgility passes a list of field names that were requested for validation. For full document validation, all document field names are passed. Using this parameter, custom logic may only validate required fields or apply any other logic based on fields requested for validation.

If the map does not satisfy the above requirements, the rule assignment is rejected, and appropriated message is displayed.

The process output is ignored by TotalAgility so it can have any or no output variables.

The post validation handler process map implements any custom logic after standard validation is executed. This map can freely read and modify data during its execution using batch-aware SDK API calls. The process map does not have output and is fully responsible for changing the state of data it operates.

All CaptureDocumentServices APIs are batch aware.

The process map is an integral part of standard validation and is thus always executed whenever standard validation is executed. If the post validation handler is not configured, it is skipped.

When validation is executed from the capture form, the form reflects all field changes in the user interface automatically.

Standard validation does not support calling TotalAgility SDK API that modifies capture data. TotalAgility does not prevent anyhow from actual calling data modifying SDK, but it is not supported. You may use it at your own risk.

Runtime behavior

If the post validation handler has changed field status (Valid, Forced Valid, Invalid, or Confirmed) or error message, this change overrides any standard validation rule result assigned to this field even if the changed state contradicts the standard rule logic. If the updated status is set as valid, then the corresponding standard rule is treated as “passed” until the field value is changed.

If the post validation handler has changed some field status and this field is part of some multi-field rule, the status in the result of this multi-field rule is updated accordingly. If all fields that are part of this multi-field rule are valid after this update, the multi-field rule is treated as “passed” until the value of any of these fields is changed. And vice versa: if all multi-field rule’s fields were valid, but post validation sets any of them as invalid, the multi-field rule is treated as not “passed”.

If the post validation handler made an update of field status, the behavior remains the same as the same update done by the standard rule.

If the post validation handler changed field status, the field’s property ExtractionConfident is automatically set as true.

It is assumed that field status is updated using SetDocumentFieldStatus SDK. This SDK also correctly propagates status up to hierarchy.

Validation based on document type

CaptureDocumentService exposes the following APIs that trigger validation not on document, but on the document, but on document type and fields data:

  • ValidateAllDocumentFields

  • ValidateDocumentField

  • ValidateDocumentFields

When validation is triggered by these APIs, you cannot use SDK APIs that access document’s data because there is no document object. Thus, post validation configuration is ignored for these APIs and not executed.