Resolve relations

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

1. Add a node after the action producing the rows to resolve.
2. Find Resolve Relations in the Search actions... box, under the Data group.
3. In the side panel, set the three things it needs:
   • Reference Data Object: where the referential records live, for example Sub Funds.
   • Match: one or more pairs of an incoming column and a reference attribute.
   • Output Column: the column to write the matched record's id into.
4. Choose what should happen When a key is not found.

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 Match rule 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 rules and they form a composite key: a row matches only when every rule 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 in two rules would make the key ambiguous, and the action rejects it.

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

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 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.

For each item, or for a selection of them, choose a decision:

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.

Where to go next

• Human-in-the-loop
• Save records
• Executions
• Build a workflow