Overview
On 17 September 2026, Fenergo identified an issue with the Conflict Resolution task. In specific circumstances, when a Conflict Resolution task was completed, values entered or changed during a journey were not saved to the verified entity record. The previously verified values stayed in place instead. For the full root cause analysis, see Conflict Resolution Issue – September 2026.
To support remediation, Fenergo has given a Conflict Resolution Report. This report lists every journey in your tenant where this happened, and which fields were affected.
This article explains:
1. What each column in the report means.
2. How to decide whether an affected field is material to your organisation.
3. How to compare the report with the entity data in Fen-X.
4. How to record your decision in Column C (Client Request Action) and return the report to Fenergo.
Report structure
The report is an Excel workbook with two sheets:
Sheet | Purpose |
<tenant-name> | The impact data. One row per affected journey. |
Lists | The allowed values for the Client Request Action drop-down in Column C. Do not edit this sheet. |
Column reference
Col | Column name | What it means | How to use it |
A | Tenant | Name of the Fen-X tenant the row relates to. |
|
B | Tenant Id | Unique identifier (GUID) of the tenant. |
|
C | Client Request Action | Your decision for this row. Every row starts as Decision required. | Select one value from the drop-down. See Recording your decision. This is the only column you need to edit. |
D | Journey Id | Unique identifier of the journey in which the affected Conflict Resolution task was completed. | Use it to open the journey in Fen-X and see which values were entered during the journey. |
E | Journey Type | Name of the journey as configured in your tenant (for example Client Onboarding, Periodic Review, Maintenance). | Use it to prioritise. For example, onboarding and review journeys usually feed risk and screening outcomes. |
F | Journey Status | Status of the journey when the report was generated: Complete or In Progress. | See Journey Status considerations. |
G | Fields Overwritten | Number of distinct fields affected in this journey. | A quick measure of how much each journey is affected. It matches the number of fields listed in Column H. |
H | Overwritten Fields (could be from Main Entity draft or RP Drafts) | Semicolon-separated list of the affected fields, identified by their field key (system name, for example legalEntityType), not by their screen label. | For these fields, the value entered during the journey was not saved to the verified record, so the previous verified value was kept. Review each field. A field can belong to the main entity or to a related party (RP) draft captured in the same journey. |
I | EntityId | Unique identifier of the main entity the journey was run for. | Use it to open the entity profile, or to filter the entity data report for comparison. |
Step-by-step: how to review the report
Step 1 – Translate field keys into business fields
Column H shows field keys (system names). To find the screen label for each one:
· Go to Policy in Fen-X. Open the relevant Requirement Set / Entity Policy (or the Data Group, for collection fields) and search for the field key.
Tip: The same field key often appears across many rows. Before you review rows one by one, build a unique list of all field keys in Column H. In Excel, split Column H by ; and remove duplicates. You then only need to assess each field's materiality once.
Step 2 – Assess the materiality of each field
A field is material if an incorrect value could affect a compliance or operational outcome. Check each unique field against the following:
Consideration | Questions to ask | Typical examples |
Risk assessment | Is the field an input to a risk model factor or rule? Is it a risk output? | Entity type, country of incorporation/residence, source of funds/wealth, industry/occupation, expected activity values/volumes, PEP status, risk rating fields |
Screening | Is the field sent to, or used to match against, a screening provider? | Legal name, aliases, date of birth, nationality, addresses, registration numbers |
Policy scoping and journey logic | Does the field drive which requirements, documents, tasks or related-party requirements apply? Does it trigger a journey or review? | Entity type, jurisdiction, product, client type, review frequency |
Downstream integrations | Is the field sent to a downstream system through an outbound integration, webhook, data export or API consumer? | Core banking, CRM, account opening, regulatory reporting feeds |
Regulatory / reporting | Is the field used in regulatory reporting or audit evidence? | Classification fields (e.g. FATCA/CRS), LEI, tax identifiers |
Low impact | Is the field informational only, with no rules, risk, screening or integration dependency? | Free-text comments, contact details, migration/reference fields |
Classify each field as Material or Non-material. Any row that contains at least one material field should be prioritized.
Step 3 – Compare against the current entity data
For each affected row, compare the value currently on the verified record with the value that was intended during the journey:
1. Current verified value. Generate the entity data report using the steps in Steps to use Swagger to generate a Conflict Resolution Report. Filter it by the EntityId (Column I). Alternatively, open the entity profile in Fen-X.
2. Intended value. Open the journey using the Journey Id (Column D) and look at the value captured for the field in the journey's data tasks.
3. For related-party fields: If a field is not on the main entity, check the related parties added or updated in the same journey. The Column H header notes that fields can come from related-party drafts.
Then decide:
· If the current verified value is correct or acceptable, no data correction is needed.
· If the intended value should have been saved and the difference is material, a correction is needed. Also consider whether any risk, screening or downstream outcome that used the stale value needs to be re-run.
Step 4 – Record your decision in Column C
See the next section.
Step 5 – Return the report
When every row has a value other than Decision required, return the completed workbook to Fenergo Support on your existing support ticket for this matter.
Recording your decision (Column C)
Select one value per row from the drop-down list:
Value | When to choose it | What happens next |
Restore values for entity reassessment | The intended values should be on the verified record, and at least one affected field is material to risk, screening, policy scoping or another evaluated outcome. | Fenergo restores the values captured during the journey to the verified record, so the entity can be reassessed (for example, risk recalculation or re-screening) based on the corrected data. Required here is the JourneySchemaID for the JourneyType to be triggered |
Restore values only | The intended values should be on the verified record, but the affected fields are not material to any evaluated outcome. Data accuracy is the only concern. | Fenergo restores the values captured during the journey to the verified record. No reassessment is triggered. No Journey will be triggered. |
Take no action | The current verified values are correct or acceptable. For example, the value was later corrected manually, a newer journey has superseded it, or the difference has no business impact. | No change is made to the entity. |
Journey Status considerations
Status | What it means for review |
Complete | The journey finished with the previous (stale) verified values in place. Any risk assessment, screening, approval or integration that ran after the Conflict Resolution task may have used those values. Prioritize these rows when the affected fields are material. |
In Progress | The Conflict Resolution task completed, but the journey is still open. Confirm the current values on the entity before the journey is completed, because later tasks in the journey (for example risk or screening) may use the stale values. |
Also check whether the entity has had another journey since the affected one. If so, the field may already have been updated, and Take no action may be the right choice.
Frequently asked questions
Q: Does the report show the actual values?
No. The report shows which fields were affected in which journey, not the values. Use the entity data report and the journey itself (see Step 3) to compare the values.
Q: Why are field names shown in a technical format?
Column H uses the field key from your policy configuration. See Step 1 for how to map keys to screen labels.
Q: The same entity appears in more than one row. Why?
Each row is a separate journey. If the issue affected an entity in more than one journey, each journey appears as its own row and needs its own decision.
Q: A field in Column H isn't on the main entity. Where do I find it?
It likely belongs to a related party that was captured or updated in the same journey. Check that journey's related-party data.
Q: Has the issue been fixed?
Yes. A corrective fix was applied on 19 September 2026, and Fenergo has identified no further occurrences since then. The report covers the period from 9 to 19 September 2026.