Skip to main content
Version: 18

Migration Guide

Inspecting information exchanges​

Customers who are using the DOSSIER_INFORMATION_EXCHANGE module for information exchanges towards an intermediary and have the flow option IMPERSONATE_NO_OTP configured, will have a better user experience when migrating to the new flow option of type INSPECT.

Reminder action upgrade (V1 → V2)​

The reminder event actions ScheduleInviteCounterpartyReminder and RemindCounterpartyOnInformationExchangeCompletion have been deprecated in favor of ScheduleInviteCounterpartyReminderV2 and RemindCounterpartyOnInformationExchangeCompletionV2. The V2 actions add per-invitation-type filtering and per-reminder-index configuration.

To upgrade an FSP definition:

  1. Replace ScheduleInviteCounterpartyReminder with ScheduleInviteCounterpartyReminderV2 in the action bound to DOSSIER_COUNTERPARTY_INVITED.
  2. Replace RemindCounterpartyOnInformationExchangeCompletion with RemindCounterpartyOnInformationExchangeCompletionV2 in the action bound to DOSSIER_INFORMATION_EXCHANGE_COMPLETION_REMINDER.
  3. Configure the V2 settings on each: invitationType (FLOW / INFORMATION_EXCHANGE / SIGNATORY) plus a reminders map keyed by reminder index. See ScheduleInviteCounterpartyReminder and RemindCounterpartyOnInformationExchangeCompletion for the settings shape and examples.
warning

The V2 actions handle one invitationType per binding. If your FSP definition previously used a single V1 binding for multiple invitation types (e.g. both FLOW and INFORMATION_EXCHANGE), bind one V2 action instance per invitation type you need to handle, otherwise reminders for the missing type(s) will silently stop firing.

Dossier type and service are free text​

The dossier type and the dossier service are no longer fixed enumerations. They are free text values now, filled from a configurable autocomplete list. The old enum values are kept as their string equivalents, so existing dossiers and configuration keep working, but everything that relies on the old closed set has to be reviewed:

  • Configuration and integrations that send, compare or filter on a dossier type or service now work on strings. A custom type or service is added on a dossier definition, which has to be linked to the FSP definition. Its label comes from the white label translations FRONT_END.VALUE.DOSSIER_TYPE.<value> and FRONT_END.VALUE.DOSSIER_SERVICE.<value>.
  • Reports and data warehouse consumers that map on the old enum values have to be reviewed, since both columns can now contain configurable string values.
  • The INSURED_PERSONS and BENEFICIARY modules no longer depend on the INSURANCE module or type, and a dossier of type INSURANCE does not always have an insurance reference anymore: the insurance data is only created once it actually holds data. Custom code and queries that assume the reference is there have to handle its absence.

The database migrations for this change are part of the release, so there is no manual data migration.

See the Dossier definitions for the configuration.

Insurance validations are deprecated​

The validation classes InsuranceIbanRequired and InsurancePremiumIsPositive are deprecated. Both check insurance data with logic that is fixed in code, and InsurancePremiumIsPositive only runs for dossiers of type INSURANCE. Now that the dossier type is free text, that condition belongs in the configuration. Replace both with the generic HarmoneyDossierDataValidation, which performs the same checks through its settings. The deprecated classes keep working until they are removed in a later release.

The deprecation notice on each class contains the exact HarmoneyDossierDataValidation settings that reproduce its behaviour. Copy those settings into the status transition configuration that references the deprecated class.

See the HarmoneyDossierDataValidation for more information.

New languages have to be activated per white label​

The application now supports 28 languages, but a new language only appears in the language picker after it has been activated on the white label. After upgrading, activate the languages you want to offer on each white label. The languages that were already active keep working as before.

See the White label details for more information.

Questionnaire flow steps from before V17​

Flow definitions that still use the questionnaire configuration from before V17 do not have to be converted by hand. A migration is available in the admin that converts the old questionnaire flow step configuration for the whole organization at once.

clearManualAssessmentOn replaces lockManualAssessment​

In the assessment settings of the RBA module, lockManualAssessment is replaced by clearManualAssessmentOn. Existing FSP definitions are migrated automatically. Do check the migrated value, since it determines when a manual assessment is cleared: on every change in the due diligence information used for the RBA calculation (the default), only when the RBA rating increases, or never.

See the RBA Module for more information.

enableStatuses on the IDENTITY and UBO modules​

The IDENTITY and UBO modules have a new enableStatuses setting, which determines whether the identity and the UBO structure have a status at all. Existing FSP definitions are migrated with the setting enabled, so nothing changes for them.

When the setting is absent, status management is off. It therefore has to be set to true explicitly on FSP definitions that the migration does not cover, for example one that is created after the upgrade or imported from an older export. Without it the status is not shown, the approval status transitions do nothing, and the validations that require an approved identity or UBO structure no longer block a status transition, a due diligence check or an RBA calculation.

See the Identity Module settings and the UBO Module settings for more information.