Foundational Setup Order

When configuring a new client implementation, the order in which you set things up matters. Dependencies exist between configuration areas — for example, you cannot configure workflow actions until you have a business class, and you cannot configure document generation until you have workflow actions.

The table below gives the recommended sequence. Following it minimises rework and avoids the frustration of configuring something that has an unmet prerequisite.

Step	Area	What to configure
1	Trading Party & Application Settings	trading-parties/{client}-insurer.json, homePartyId in be_config.json, base currency, domicile, date format, address settings
2	Business Class (LOB)	business-class/{name}.json — typeCode, name, enabledPlacingTypes, products, sendPasEnabled, useSendRating
3	Workflow (Risk Actions)	actions/{bc}/{bc}-{pt}-actions.json — the sequence of actions for each placing type
4	Submission Forms	applicationconfig/{pt}_submission_config.json — fields on the new risk and edit risk forms
5	Risk Record & Document Repository	Document storage config, naming, lifecycle. Screen meta data for core risk action sections
6	UW Dashboard & Search	be_config.json: risks_board_config. ui_config.json: search settings
7	Task Management	task-templates/ — pre-defined tasks with data capture
8	Rating	DynamoDB config: rulesEngineBaseUrl, rulesEngineDatasourceUrl. Rules files
9	Document Generation	document-template/ and document-clause/ config and files
10	Clause Library	ui_config.json: features.clauseLibrary. DOC_ADMIN role. document-clause/ files
11	Smart Submissions	be_config.json: smartSubmissionConfiguration. Gmail sync, triage rules
12	DUA (if applicable)	featureSwitches.DUA, duaConfig, master_submission_config.json, dua/ directory

Why this order?

Steps 1–2 are mandatory prerequisites. Workbench will not start without a valid trading party definition. A business class must exist before you can configure workflow, forms, or documents for it.

Steps 3–5 form the core delivery. Together they give the underwriter a usable workflow: they can submit a risk, complete actions, and store documents. Most UAT environments need at least these three steps working.

Steps 6–8 are quality-of-life and integration. Dashboard configuration, task management, and rating can often be configured in parallel with steps 3–5.

Steps 9–10 are often on the critical path for testing. Document generation needs to be in place before QA can test the full quote-to-bind workflow. Prioritise these if UAT is approaching.

Steps 11–12 are advanced features. Smart Submissions and DUA require additional infrastructure and configuration. They should be planned as separate workstreams and should not block delivery of the core platform.

Deploying configuration

For all non-local environments, deployments are requested through the Send Partner Portal at https://send-partner-portal.refined.site. This applies to all files in the repository — business config under config/ and environment profile files under dynamodb/. You edit the files and raise the portal request; the deployment is handled for you.

The environment progression is: PDE (local) → Dev → SIT → UAT → Production.

• Dev: Raise a Client Build & Deploy request — branch-based, no version tagging needed
• SIT / UAT: Raise a Create Client Microservice Version request first, then a Deploy Client Microservice Version request. If you have DynamoDB changes, always deploy those first via a Deploy DynamoDB Changes request
• Production: Managed by the Send release management team following formal UAT sign-off

After deployment, Workbench picks up business config changes on its next periodic configuration refresh. DynamoDB changes require a service restart — this is handled as part of the portal request.

See Multi-Environment Config Promotion and the Partner Portal Reference for full details, or the Send Partner Documentation for official Send deployment docs.

Next steps

Start with Trading Parties — the mandatory first step for any implementation.