Skip to main content
Version: 18

Validations

Business goal​

Validations (often called "completion checks") will at certain points in the application validate (check) whether a certain step is completed, or if all minimum requirements are met before a next step can be started.

Implementations​

See Validation classes for more information.

Configuration​

Type​

  • Advice (ADV)
  • Dossier status transition (DST)
    ℹī¸ Most validations are included in the Status Transition Configuration (JSON or class). In exceptional cases, custom validations are defined (e.g. removing default validations).
    • Enum Value: This value corresponds with the DossierStatus the user wants to transition to.
  • UBO status transition (UBO)
  • Identity status transition (ID)
  • Flow step precondition (FSPC)
    ℹī¸ Allows a flow step to be unavailable for the current user.f
  • Flow step completeness (FSC): Checks whether all data for a given flow step is available.
    • Enum Value: This value corresponds with the FlowStep for which the validation must be performed
  • Conditional AML (AML)
  • RBA
  • Due diligence precondition (DDPC)

Generic Validation settings​

Some implementations have highly configurable validation possibilites, referred as 'conditions'. Below you can find more details on how such validations/conditions are configurable.

Validation Concept

Validation Concept​

The validations are a list of Validation objects (see below). Each Validation consists out of 3 parts:

  • An optional condition, holding a ConditionDTO object (see below)
  • A validation, holding a ConditionDTO object (see below)
  • An optional errorCode.

Note that an optional errorCode can also be added next to validations as a global fallback code for individual Validation objects what would not have their own errorCode. If any validations are configured, there must be at least a global errorCode, or every validation must have its own errorCode.

ConditionDTO​

Both the condition and the validation fields hold a ConditionDTO object. This object evaluates to true or false. In this model, it is possible to combine the evaluation of different fields using operators such as and, or and not. The evaluation itself can be performed using the following comparisons:

  • equals, notEquals
  • like, notLike. Optionally using wildcards (%).
  • in, notIn. Only for collections.
  • contains, notContains. Only for multi-value fields.
  • greaterThan, smallerThan. Useful for checking if numeric values are in a certain range.
  • isNull, isNotNull. Useful for checking on requiredness of fields.

See the Condition reference for the full list of operators, the supported value shapes and examples.