Submission Forms: Overview¶

The submission form is the multi-step wizard a user sees when creating a new risk. It is also used for the edit risk pop-up. Both views are driven by the same configuration file.

Config file¶

config/{client}/applicationconfig/open_market_submission_config.json

Other placing types have their own submission config files in the same directory. The base repository ships with open_market_submission_config.json, master_submission_config.json, dec_submission_config.json, coverholder_submission_config.json, and smart_submission_config.json.

Pages and steps¶

The form is divided into steps (pages), defined in the steps array. You can add, remove, or rename steps.

{
  "steps": [
    {
      "title": "Risk Details",
      "fields": [ ... ]
    }
  ]
}

Tip

For most workflows, a single step is preferred to keep the submission flow simple. Only add additional steps when there is a clear grouping rationale and the form genuinely benefits from pagination.

Core fields vs custom fields¶

Field type	How to identify it
Core field	Has a `name` property referencing a core field key (e.g. `riskProcessingStatus`, `contractType`, `brokerParty`)
Custom field	Has a `customFieldConfig` object instead of (or in addition to) a `name` property

Core fields are provided by the Workbench platform and have fixed backend behaviour. Custom fields store their values in the risk_value table and require backend handling.

Views¶

The views array on a field restricts which context the field appears in. If no views are specified, the field is visible in all views.

View key	When it is shown
`manualSubmission`	New risk creation form (the + button flow)
`editRisk`	Edit pop-up shown when user clicks Edit on an existing risk
`smartSubmission`	Smart Submissions / Send Flow email-to-risk form
`rate`	Rating view — fields shown during the rating workflow

Tip

Best practice is to avoid adding view restrictions unless there is a genuine reason. Use displayConditions instead for conditional visibility based on field values.

Display conditions¶

Use displayConditions to show or hide a field based on field values or the active view. This is the preferred mechanism for conditional visibility.

Show a field only when riskType is MTA:

{
  "displayConditions": [{ "field": "riskType", "value": "MTA" }]
}

Show a field only in the editRisk view:

{
  "displayConditions": [{ "view": "editRisk" }]
}

Overrides¶

Use overrides (with modifierClass: hide) to modify the default behaviour of a core field without replacing it. Common uses: change the default value of a hidden field, override a field label, or suppress a core field.

Note

Do not confuse overrides with displayConditions. displayConditions controls visibility dynamically at runtime; overrides change field behaviour statically in configuration.

Hidden fields with default values¶

Some fields must be present in the form submission to satisfy backend validation but should not be shown to users. Configure them as hidden with a fixed default value:

Field	Why hidden / default
`riskProcessingStatus`	Initial status is always `LOGGED`. No user choice needed.
`contractType`	Defaults to the client's standard contract type.
`currency`	May be defaulted to GBP for certain risk types.

Applying changes¶

Raise a PR with the updated config and have it merged
Raise a Client Build & Deploy (Dev) or Deploy Client Microservice Version (SIT/UAT) request in the Send Partner Portal
Workbench picks up the change on its next periodic configuration refresh
Open the new risk form or edit pop-up to verify changes

Note

The edit risk pop-up and new submission form share the same config. Changes affect both unless scoped using displayConditions or views.