Related Parties

Users may notice duplicate entries for the same Related Party when exporting data or running reports, even though the Related Party appears unique within the UI. This typically happens when multiple active associations reference the same Related Party entity, or when historical relationships were not properly deactivated during ETL merge processes. In some cases, duplicates can also result from reporting queries that join on non-unique fields such as entityName instead of unique identifiers like entityId or alternateId.

Users may notice that Related Party tasks show stale or incomplete details, even when the Related Party record or its associations have recently changed in another Journey, through an API update, or via an ETL process. This occurs because Related Party tasks in Fenergo display a snapshot of data captured at the moment the task was first opened. Any updates made outside the active Journey context are not automatically reflected until the task is refreshed or reinitialized.

It’s common to expect that once an association (for example, between a Client and a Related Party) is created in one Journey, it should automatically appear in other active Journeys. However, in Fenergo, each Journey instance operates on its own data snapshot, meaning changes made within one Journey remain local until they are verified and promoted. Associations created during a Journey stay in draft form until verified — only then do they replace the previously verified records and become globally visible across all other Journeys.

When adding logic to Related-Party requirements, what should the ‘Source’ be for the trigger conditions?