Resolve relations
Link incoming rows to your reference data, and let a reviewer create the records that are missing.
Incoming data almost always references things you already hold: a position names a sub-fund, a transaction names a counterparty. Resolve Relations does that lookup as one step. It matches each incoming row against a reference data object on a key you choose, writes the matched record's id into a column, and, when a key is nowhere to be found, hands the problem to a person instead of failing the run.
The reviewer's job is the reason the action exists. They see one question per unknown key, not one per row, and they can create the missing reference records in bulk from the review screen.
Add the step
- In the editor's Configure tab, select the step producing the rows to resolve, then find Resolve Relations in the Data group (or type it into Search actions...). It is added after that step.
- In the side panel, fill in its cards:
- Reference Data: the data object where the referential records live, for example Sub Funds.
- Match strategy: keep Key Match, then under Key columns pair each incoming column (for example
s_id) with a Reference attribute. - Output column: the column to write the matched record's id into, for example
subfund_ref.
- Choose what should happen When a key is not found: Send to review, Keep row, Drop row or Fail run. With Send to review, Copy matching columns into new records lets a reviewer's new record be filled in from the incoming columns the reference data also uses.
The Match strategy card also has a Similarity Search tab, which describes matching on how alike the values are, through Columns to compare. It is not built yet: choosing it changes nothing about how a run behaves, and the choice is not saved.
There is deliberately little else to configure. What the reviewer sees is derived at run time from the reference object and the incoming columns, so you pick the object and the key and you are done.
The match key
Each key column maps one incoming column onto one attribute of the reference object, for example the column s_id onto the attribute Sub-fund code. Add several and they form a composite key: a row matches only when every pair matches.
Two things to know:
- Comparison is exact. There is no operator to choose, because the underlying record lookup does not honour one. Normalize the values upstream if they need it, for example with Map Data Fields.
- A column can only appear once. Using the same incoming column twice would make the key ambiguous; the panel says This column is already used in the key.
The reference attribute is picked from a list of that object's real attributes, so it cannot be a typo.
When a key is not found
| Choice | What happens to the row |
|---|---|
| Send to review | Pause and ask a person, once per distinct key rather than once per row |
| Keep row | Emit the rows with an empty reference column |
| Drop row | Remove the rows from the output |
| Fail run | Stop the workflow |
Send to review is the default and the point of the action. The other three are there for the cases where an unknown key is genuinely not worth a human's attention.
Copy matching columns into new records is on by default. When a reviewer creates a missing reference record, it is pre-filled from every incoming column whose name the reference object also uses. The key itself is always pre-filled; this covers the rest. Turn it off when the two objects happen to share a column name that does not mean the same thing.
Review the unmatched keys
A run that hit unknown keys pauses with the Awaiting review status, and the review appears in the Interventions tab (Ecosystem › Workflows › Interventions) alongside any other pending work. See Human-in-the-loop for how that tab works.
Open the review and each row is one unknown key, not one incoming record. Eight hundred valuation rows referencing two unknown sub-funds are two questions, and each item shows a preview of the rows it stands for so you can see what is waiting on your answer.
Select one item or several with their checkboxes, then pick a decision from Select action...:
| Decision | Use it when |
|---|---|
| Approve | The reference record does exist; pick it and the rows are linked to it |
| Create new records | The reference record is genuinely missing and should be added |
| Approve without linking | The rows should continue with no reference set |
| Reject | The rows should not continue |
With Approve, a reference picker appears beside the decision, so one reference record can be applied to everything selected. Click Apply to submit. Whatever you decide for one key is applied to every row that shares it.
Create the missing records in bulk
Choose Create new records and a dialog opens with one row per key and one column per attribute of the reference object. Every cell is editable and pre-filled with what the incoming data carried, so in the common case you are confirming rather than typing.
Fill in anything the delivery did not supply, then submit. The records are created in the reference object, the waiting rows are linked to them, and the run continues. From then on that key matches on its own.
Decisions are not remembered between runs, and that is deliberate. Once a reviewer has linked or created a reference record, the key matches on its own the next time, so a remembered mapping would only ever be an entry that can never fire again.