Filing an assessment against the right application, however it was typed

The scenario fires when the assessment item is created, then sleeps for thirty seconds. A form creates the item first and fills its columns afterwards, and reading too early means filing a record of blanks.

It tries the explicit relation first, and falls back to the text before the dash in the item name: names arrive as 'Candidate – Employer'. If nothing matches, the id becomes zero, which is a query that finds nothing rather than a query that breaks.

One request holds two lookups: the candidate's most recent application whose name contains the employer text, and simply their most recent application. The scenario uses the explicit link if the form made one, then the employer match, then the latest, so a careful submission is honoured and a careless one still lands somewhere sensible.

The assessment becomes a subitem named after the candidate, with each rating mapped by its label text. The mapping does not create missing labels, so a typo on the form cannot add a stray option to the board's drop-down.

The subitem points at the candidate and the source assessment, and the assessment is then written back with the application and the new subitem. The result is auditable from either record.