Actions¶
Risk actions are the discrete steps an underwriter completes on a risk. They appear as buttons on the risk record and can have pop-up forms, prerequisite relationships, and trigger server-side pipelines.
New to actions?
Start with Anatomy of a Risk Action for a full walkthrough of the JSON structure, field-by-field explanations, verified examples, and the connection map between actions, pipelines, screen meta data, and business constants. This page covers the supplementary detail.
Core actions vs custom actions¶
| Type | Description |
|---|---|
| Core (fixed) | Behaviour and UI fields are defined in the Workbench core platform. Labels can be changed but fields and behaviour cannot. |
| Custom | All fields in the pop-up are defined in a screen meta data JSON file. Fully configurable. |
Action config file¶
Risk actions for a business class are defined in:
Key fields¶
| Field | Description |
|---|---|
code |
Unique identifier. Never change this once in use — changing the code breaks dashboards and action history. |
label |
Display label shown to users. Sourced from the action business constant. |
actionGroupCode |
Groups the action into a visual section on the risk detail view. |
placingType |
The placing type this action applies to (e.g. OPEN_MARKET, MASTER, DEC, COVERHOLDER, FAC_RI, CLAIM). Must match the business class placing type. |
actionPrerequisites |
Array of action codes that must be completed before this action becomes available. |
initialPipeline |
Pipeline to run when the action first becomes available (not when completed). |
completionPipeline |
Pipeline to run when the user completes (submits) the action. |
displayCriteriaExpression |
JSONPath expression to control whether this action is visible. |
embedDocumentGeneration |
true to embed document generation within this action's completion flow. |
statusMappings |
Maps action state keys to action statuses (COMPLETE, FAILED, IN_PROGRESS). |
Warning
The action code must match the operationName in the screen meta data config file. A mismatch means Workbench cannot find the pop-up definition — the action will open with an empty or broken form.
Operations and business constants¶
Each button on a risk action pop-up is an operation. Operations reference two business constant files:
business-constants/action.json— maps action codes to display labelsbusiness-constants/operation.json— maps operation codes to button labels
Add your action code and operation code to the respective files before reloading configuration. Missing codes appear as raw codes in the UI.
Prerequisite chains¶
Use actionPrerequisites to enforce ordering:
This action will only become available once both appetite_check and risk_structure are complete.
Initial vs completion pipelines¶
| Trigger | When it fires |
|---|---|
initialPipeline |
When the action first becomes available (not when completed). Useful for pre-populating data before the user opens the action. |
completionPipeline |
When the user completes the action by clicking Save/Submit. |
Tip
If two pipelines would always fire together, combine them into one pipeline definition. Use separate pipelines only when they have independent trigger points.
Sub risk actions¶
Sub risk actions allow multiple distinct pop-ups to be grouped under a single parent action in the UI. Each sub-action can have its own operation, pipeline, and screen meta data.
- Sub-actions are configured in the parent action's JSON by nesting sub-action definitions
- The screen meta data is loaded based on the sub-action's operation name, not the parent action's code
- Core risk actions can be reused as sub-actions with limited configurability
Applying configuration changes¶
- Raise a PR with updated JSON files 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 refresh
- Refresh the browser and verify the action appears with the correct label, order, and prerequisites
Note
After the refresh, the action pop-up will only show correctly if the screen meta data is also correctly wired up. A missing or misconfigured screen meta data config results in an empty pop-up or an error.