This KBA describes a scenario that has been raised by multiple clients around data being ingested & overwritten by parallel journeys. The Conflict Resolution task can be configured to account for these situations, but in some cases, clients are running journeys from schemas without Conflict Resolution. We explore the best options in such scenarios.
Example scenario - solve using Conflict Resolution
Example: the following sequence of events has happened:
· Journey A (Onboarding) is launched.
· Data group 'Request Information' filled out with 4 fields.
· Journey B (Onboarding) is launched.
· In journey B, the same data group is filled out with 4 different entries for the same fields.
· Journey B is completed. The data captured in this journey is verified.
· Journey A is completed. At this point, the DG fields from Journey B are overwritten by the entries in Journey A in the verified entity record. Only the entries from Journey A are present.
The client wants the DG entries from both journeys to appear on the verified entity record. The Conflict Resolution feature in Fen-X allows users to manage entity data in their current journey when the entity data has been changed and verified in a journey outside of the current journey. If Conflict Resolution is configured in the Onboarding journey, they can select both DG entries when prompted in the task (both entries are now included in the verified entity record once this Onboarding journey is completed:
More on the functionality offered by the Conflict Resolution task: https://docs.jpm.fenergox.com/user-guides/conflict-resolution-and-proposed-changes
If client doesn’t have a Conflict Resolution task configured in their journey schema…
If the client does not have Conflict Resolution configured on their journey schema, the above is not possible. As this task was rolled out in May 2022, clients should be encouraged to use it in their journeys. The following explains why the 2 data group entries exist separately to each other, and will not both be added to the verified record without manual intervention/Conflict Resolution:
Without Conflict Resolution, each individual data group record exists in isolation really, so the collections between Journey A and Journey B don't really co exist, more so that one gets verified over the other.
The reason for this, is that a data group within entity-data exists as a collection. It is compromised of individual data group records.
On Journey A, four properties were added to the “collections” array, each containing the unique ID for that data group record. Example of 5a687efb-5d… below:
On Journey B, four new properties were added. This obviously means a sum total of 8 data group record IDs – or “collections”. The initial four “collections” from Journey A and the latter four from “Journey B” have no connection to one another, unless the Conflict Resolution task has been brought into scope.
When Journey A was initiated, the “Request Information” data group has no collections on its datakey. Journey A, four were added, but crucially the Journey was not verified. This means that when Journey B was spun up, it took what was on the entity record at the time – a null “requestInformation” collection – and created the entity draft for Journey B.
As Journey B completed before Journey A, you are therefore seeing those data group records (“collections) captured within the Journey A context.
Best contingency options
Manually ensure that all Data Group Records are aligned between Journey A and Journey B. This could be done by adding the DG entry from both journeys to whichever journey is due to be completed & verified last.
Try to avoid parallel journeys by ensuring that the data of Journey A is verified to the entity record before launching Journey B.
Launch a Journey C in which you add whatever data is missing.