Repository Structure¶

All Send Workbench configuration for a client lives in a single Git repository (conventionally named send-{client}). This is the primary workspace for all configuration delivery. Every JSON file you create or edit in this repository translates directly into platform behaviour.

Top-level directories¶

The following directories exist in the base repository (config/senduk/). Not every client will use all of them — omit what isn't needed for your implementation.

Directory	Purpose
`actions/{bc}/`	Risk action workflow definitions per line of business and placing type
`applicationconfig/`	`be_config.json`, `ui_config.json`, `*_submission_config.json` forms, theme files, `risk_overview_config.json`, `risks_board_config.json`, `search_config.json`, `smart_submission_config.json`, `custom_risk_tabs_config.json`, etc.
`bordereau-templates/`	Bordereau Excel templates (e.g. `LLOYDS_2020_10.xlsx`) used for DUA declarations
`business-class/`	Line of Business (LOB) definitions
`business-constants/`	Shared lookup dictionaries: actions, products, currencies, countries, and custom lookups
`contacts/`	Contact / party-related static data
`document-clause/config/` and `files/`	Clause library definitions and content
`document-template/config/` and `files/`	Document generation HTML templates and config (singular — `document-template`, not `document-templates`)
`dua/`	DUA-specific config: coverholder and master screen meta data, DUA action files, UW rationale, and related assets
`dynamodb/{environment}/data.json`	Per-environment profile file deployed to DynamoDB (the base repository ships `dev/` and `prod/` only — add `uat/` if your client uses a UAT environment)
`external-iframes/`	External iframe embeds referenced from the UI
`minimal-data/`	Seed data loaded on startup when `loadMinimalDataOnStartup` is enabled
`nlp-analysis/`	NLP/text-analysis configuration
`party/`	Party records and configuration
`pipelines/`	Pipeline definitions for server-side REST call sequences (includes subfolders for `dua/`, `individual-dec/`, `pas/`, `stp/`, etc.)
`question-group/` and `questions/`	Questionnaire and data capture question definitions (note: `question-group` is singular)
`rate-tolerance/`	Rate tolerance definitions
`rating/`	Rating configuration (multiple subdirectories for rater types)
`role/{environment}/`	User role definitions per environment
`rules/`	Rules engine rule groups, individual rules, and data mapping schemes
`screen-meta-data/config/` and `files/`	Custom screen and core risk action screen meta data
`search/`	Search index / search screen configuration
`task-templates/`	Pre-defined task templates with data capture forms
`trading-parties/`	Trading party (insurer) definitions — mandatory for startup
`uw-rationale/`	Underwriting rationale form configuration

Note

The base repository currently ships dynamodb/dev/ and dynamodb/prod/ — there is no uat/ profile out of the box. Add one for your client if UAT is part of the delivery.

Key files to know¶

These are the files you will work with most frequently:

applicationconfig/be_config.json — the master backend config file. Controls feature flags (featureSwitches.DUA, featureSwitches.PAS), the homePartyId, application settings (currency, date format, domicile), DUA config, and more. It sits in the config/ directory tree — it is S3 business config, not a DynamoDB record.

applicationconfig/ui_config.json — the master frontend config file. Controls feature flags visible to the UI (features.clauseLibrary, features.exemptions), auto-logout, smart submission options, and document generation tabs.

business-class/{name}.json — one file per line of business. Defines the LOB's placing types, products, constants, LOI, retentions, and coverages.

actions/{bc}/{bc}-{pt}-actions.json — the workflow definition for a business class and placing type combination. Defines which risk actions appear, in what order, with what prerequisites.

The dynamodb/ subdirectory¶

The dynamodb/ directory contains data.json files — one per environment — which define the environment profile. It is the only location in the config repository explicitly designated for environment-specific values. Edit these files directly in the repository, just like any other config file.

For any non-local environment, raise a Deploy DynamoDB Changes request in the Send Partner Portal. DynamoDB changes require a service restart — this is handled as part of the portal request.

Warning

DynamoDB changes do not take effect automatically with a business config deployment. Always raise a separate Deploy DynamoDB Changes request in the Send Partner Portal — a service restart is included as part of that request.