Skip to content

Application Config & Feature Switches

be_config.json is the most important single file in a Workbench implementation. It is S3 business config — it sits in the config/ directory tree, not in the dynamodb/ directory — and controls platform-wide behaviour: which features are active, integration endpoints, currency settings, and Smart Submission configuration.

This page explains the structure of be_config.json, the most important feature switches, and how to make changes safely.

Where it lives

be_config.json lives in applicationconfig/be_config.json and is part of the S3 business config domain. That means:

  • It is deployed via the Send Partner Portal along with the rest of the business config
  • dynamodb/{env}/data.json is the only DynamoDB record in the config repository — be_config.json is not part of it
  • Workbench refreshes its configuration periodically — no manual reload is required after a deployment

In the local development environment the equivalent file is pde.dev.json, which is mounted into the Docker stack and read at startup.

Top-level structure

The following are the actual top-level keys present in the base repository's be_config.json. Note that several blocks have non-obvious names (e.g. smartSubmissionConfiguration, ratingServiceConfiguration, documentGenerationConfig) — match them exactly.

{
  "homePartyId": "urn:duns:10838357",
  "baseCountry": "GBR",
  "assignableRoles": ["SC_FC", "SC_FC_OPS", "SF_OPS", "DUA_TEAM", "FINANCE_TEAM", "CLAIMS_TEAM"],
  "featureSwitches": "{\"DUA\": true,\"PAS\" : true}",
  "currencyConfig": { ... },
  "duaConfig": { ... },
  "documentConfig": { ... },
  "documentGenerationConfig": { ... },
  "documentClauseConfiguration": { ... },
  "externalCallConfig": { ... },
  "smartSubmissionConfiguration": { ... },
  "ratingServiceConfiguration": { ... },
  "masterRiskConfig": { ... },
  "policyConfig": { ... },
  "pricingAdminConfig": { ... },
  "clashCheckConfig": { ... },
  "additionalEntityConf": { ... },
  "uwRationaleConfig": { ... },
  "productCoversProcessConfiguration": { ... },
  "additionalCoverholders": false,
  "dunAndBradStreetAccessTokenV2": false,
  "javaScheduleMapping": false,
  "defaultAddressCleanseApi": "GOOGLE_MAPS_API",
  "countrySpecificAddressCleanseApi": { ... }
}
Field Description
homePartyId Required. The DUNS URN for the client insurer. Must match trading-parties/{client}-insurer.json. Workbench will not start without this
baseCountry ISO 3166-1 alpha-3 country code for the client's home country
assignableRoles List of role codes assignable in this client. Base repo default: 6 roles
currencyConfig Currency provider, refresh frequencies, and yearly/monthly average behaviour (no baseCurrency field at the top level)

Feature switches

featureSwitches is a JSON-encoded string, not a nested object

In be_config.json the featureSwitches value is a string containing an embedded JSON object. This is the exact shape in the base repository:

"featureSwitches": "{\"DUA\": true,\"PAS\" : true}"

Edit the embedded JSON inside the string. Do not change the field to a nested object — services parse it as a string.

The base repository enables only DUA and PAS. Verify any additional switches (e.g. sanctions, rating, AI-related flags) against the active core platform version before adding them — do not assume a switch name without confirming the service reads it.

Switch Description
DUA Enables Delegated Underwriting Authority features across the platform
PAS Enables Policy Administration System integration for the declaration lifecycle

Note

Enabling a feature switch activates platform behaviour but does not automatically configure it. For example, setting DUA: true requires you to also configure placing types, trading parties, and the DUA-specific actions. See Enabling DUA.

Smart Submission configuration

The block is named smartSubmissionConfiguration (not smartSubmission). Verified fields in the base repository:

{
  "smartSubmissionConfiguration": {
    "gmailSyncPeriodInSeconds": 60,
    "ruleBasedTriageEnabled": true,
    "useRiskTagsForEmailRiskStatus": true
  }
}
Field Description
gmailSyncPeriodInSeconds How often the email polling job runs (in seconds)
ruleBasedTriageEnabled Whether triage rules automatically assign priority scores
useRiskTagsForEmailRiskStatus Whether email risk status is derived from risk tags

Document generation configuration

The block is named documentGenerationConfig (not documentGeneration). Verified field in the base repository:

{
  "documentGenerationConfig": {
    "clientPartialTemplatesLookup": true
  }
}
Field Description
clientPartialTemplatesLookup When true, client partial templates override core partials of the same name

DUA configuration block

Required when DUA is enabled in featureSwitches. Verified keys in the base repository are duaImplementationDir and masterBordereauReportingConfiguration:

{
  "duaConfig": {
    "duaImplementationDir": "dua",
    "masterBordereauReportingConfiguration": {
      "defaultValues": {
        "bordereauType": "RISK",
        "frequencyCode": "MONTHLY",
        "expectedBordereaux": 12,
        "maxReportingReturnTermDays": 14,
        "dateFormatType": "DAY_MONTH_YEAR"
      }
    }
  }
}

See Enabling DUA for the full DUA config reference.

External call configuration

Verified keys in the base repository:

{
  "externalCallConfig": {
    "executeDuaValidationInClientSpecificAPI": false,
    "filterScreenMetaDataWithClientSpecificCriteria": false,
    "taskCreatedNotification": { /* ... */ },
    "taskCompletedNotification": { /* ... */ }
  }
}

These flags and URLs route specific calls to the client-specific API. Confirm the exact URLs and payload shapes with your delivery lead — they are typically set during integration.

Rating service configuration

The block is named ratingServiceConfiguration. Verified keys in the base repository:

{
  "ratingServiceConfiguration": {
    "sharepointHomeDirectory": "...",
    "templateDirectory": "...",
    "raterDirectory": "..."
  }
}

These point to the SharePoint/O365 rater directories used by Excel-based rating. See Rating for the full rating reference (including HyperExponential configuration, which is stored separately).

Other verified top-level blocks

policyConfig (controls MTA / renewal / skeleton policy behaviour — keys: preProcessSkeletonPolicies, copyForMta, copyForRenewal), currencyConfig (provider and refresh frequencies), documentConfig, documentClauseConfiguration, masterRiskConfig, pricingAdminConfig, clashCheckConfig, additionalEntityConf, uwRationaleConfig, and productCoversProcessConfiguration are all present in the base repository. Consult the base repository file directly for their current shape — these blocks are complex and are typically set up by Send during initial implementation.

Making changes

Because be_config.json is S3 business config, the change process is the standard config workflow:

  1. Edit applicationconfig/be_config.json in the client config repository on a feature branch
  2. Raise a PR and have it reviewed and merged
  3. Raise a Client Build & Deploy (Dev) or Deploy Client Microservice Version (SIT/UAT) request in the Send Partner Portal
  4. Workbench picks up the change on its next periodic configuration refresh — no manual reload required

Tip

For local development, you can edit pde.dev.json directly and restart your Docker stack to test changes. This file is mounted at startup and read once — there is no hot-reload.

See also