# Configurable UI (Beta)



import Image from 'next/image';

<Callout type="warn">
  This feature is currently in beta and may be subject to change. Before using it in production, please contact your Socotra representative.
</Callout>

Overview [#overview]

Configurable UI lets you customize the [Operations Workbench](https://ui-ec-sandbox.socotra.com/en/operations) for each tenant without updating code. You can change field labels, help text, and layout. You can also control who can view or edit each field, and define the steps users follow to create quotes and transactions.

These settings are stored in the UI configuration, a set of JSON files in the `uiConfigs/` folder of the tenant configuration.

The data model gives each entity its shape: its fields, types, options, and business rules. The UI configuration decides how that shape is presented: how each field renders, where it appears, and when it is shown. Presentation can also differ by entity, such as a section that appears only on renewals, using [scope](#scope-access-conditions-and-gated-variants).

Previously, presentation settings were stored in the data model as `tag` strings and `displayName` properties. The UI configuration replaces these with structured, named properties. Some older formats are still supported during the transition, but new configuration should be authored in the UI configuration.

If a tenant has no UI configuration, the Operations Workbench uses its default layout.

Use Cases [#use-cases]

Configurable UI supports a wide range of presentation changes. Some examples include:

* **Underwriting Referrals**: Locking application fields once a quote has been referred, so only users with the `Underwriter` role can edit them
* **Renewal-Specific Content**: Showing prior-term details only on renewal transactions
* **Field Guidance**: Adding tooltips that explain what a field means
* **Transaction-Specific Flows**: Giving a transaction type, such as a producer change, its own shorter sequence of steps
* **Layout Changes**: Moving a field next to related fields, or grouping fields into a new section

Key Capabilities [#key-capabilities]

* Set a field's label, value format, input control, and tooltip once; the setting applies wherever the field appears
* Control the visibility and editability of fields, sections, steps, and buttons by user role or entity data using `access` rules
* Define the journeys, workflows, and steps users follow to create quotes and transactions
* Show different titles, sections, or flows for quotes, renewals, cancellations, or specific transaction types using `scope` and gated variants
* Run [Automation Plugin](/configuration/plugins/automation) actions from buttons
* Define sections, actions, and menus once in `collections` and reuse them by name

How It Works [#how-it-works]

Where the UI Configuration Lives [#where-the-ui-configuration-lives]

The UI configuration is stored in a top-level `uiConfigs/` folder in the tenant configuration, with one subfolder per UI surface. A surface is one application, such as the Operations Workbench. Inside a surface, folders mirror the data model's entity kinds and use the same entity names, alongside a few UI-specific folders for reusable items, assets, and plugins.

<Image src="/images/configurable-ui/ui-config-folder-structure.svg" alt="The uiConfigs folder beside the data model, with mirror folders and UI-specific folders" width={900} height={470} unoptimized />

Page Kinds [#page-kinds]

A page is a screen users navigate to for a specific entity, such as an account, quote, or policy. Configurable UI supports three page kinds. All three are built from sections, but they differ in how sections are arranged and whether the page changes data.

| Page kind | Purpose                                  | Navigation                  | Changes data                 | Examples                                          |
| --------- | ---------------------------------------- | --------------------------- | ---------------------------- | ------------------------------------------------- |
| Overview  | Shows the entity and its related records | All content visible at once | Rarely, through card actions | Account 360, Policy 360                           |
| Details   | Shows the entity's full data             | Tabs, in any order          | No (read-only)               | Policy Details                                    |
| Editor    | Creates or changes the entity            | Steps, in order             | Yes                          | Quote editor, transaction editor, exposure editor |

Products can also define create dialogs, which are the modals used to start a transaction, such as selecting a cancellation type and date.

<Image src="/images/configurable-ui/page-kinds-and-navigation.svg" alt="How overview pages, the details page, create dialogs, and the editor link together for one policy" width={900} height={420} unoptimized />

Each product has one editor, which serves both quotes and transactions. Differences between quotes and transaction types are configured with scope rather than with separate editors.

Editor Structure [#editor-structure]

An editor is made up of the following nested levels:

* **Journey**: Selects the workflows shown for the current quote or transaction. The first matching journey is used.
* **Workflow**: A sequence of steps, such as submission or underwriting.
* **Step**: A single screen in the editor, containing sections and footer buttons.
* **Section**: A block of content on a step. A standard section lists the fields it displays; a typed section displays specialized content such as pricing, underwriting results, or documents.
* **Field**: Listed in a section by its path, such as `data.policyType`. Exposures, coverages, and other parts of a product's structure are called elements, and are listed as `elements.Element`, such as `elements.HO3Dwelling`.

<Image src="/images/configurable-ui/editor-nesting-and-rules.svg" alt="Journey, workflow, step, section, and field, with scope, access, and gated variants attachable at any level" width={900} height={440} unoptimized />

Field Properties [#field-properties]

A field's presentation, such as its label, input control, format, tooltip, and width, is set once in the entity's UI configuration and applies wherever the field appears, including the editor, overview pages, and the details page.

To change a field's presentation in a single section, add an inline override to that section. The override applies only to that section.

Scope, Access, Conditions, and Gated Variants [#scope-access-conditions-and-gated-variants]

The following settings control which entities and users an item, such as a workflow, step, section, or button, applies to:

* **Scope**: Defines which entities an item applies to: quotes, policies, a transaction category, or a specific transaction type. For example, a section scoped to `transaction.renewal` appears only on renewals. An item without a scope applies to all entities.
* **Access**: Defines whether an item is visible (`read`), editable (`write`), or executable (`execute`). An access rule can check the user's roles, the entity's scope, and conditions on the entity's data. Access cascades to child items: hiding a section hides its fields, and locking a step locks its sections.
* **Conditions**: Data checks used in access rules, written as `when` (grant when the condition is met) or `unless` (deny when the condition is met). For example, a commission section can be hidden while no broker of record is selected.
* **Gated variants**: Ordered lists of alternatives, selected with the same rules. Journeys, step names, section slots, section titles, and menus accept gated variants. The first variant whose rule matches is used, and a variant with no rule is the default. For example, the first step can be titled "Submission Details" on a quote and "Renewal Details" on a renewal.

Buttons and Actions [#buttons-and-actions]

Buttons appear in a step's footer, in a `buttons` section, or in a page menu. When clicked, a button runs an ordered list of actions and can then navigate to another workflow, step, or page.

Actions can be built-in, such as `save` and `validateForm`, or calls to the tenant's [Automation Plugin](/configuration/plugins/automation). Automation Plugin actions are defined once in `collections` and referenced by name. The `execute` access rule controls who can run a button or action.

Configuration [#configuration]

* The UI configuration is deployed with the tenant configuration. To change the UI, update the UI configuration and redeploy the tenant configuration. The UI configuration can't be edited in the Operations Workbench.
* A product requires only an editor that lists the fields shown on each step. All other pages and field properties are optional and use defaults when omitted.

For folder structure, properties, and examples, see the [configuration guide](/configuration/configurable-ui/overview).

Limitations [#limitations]

The following limitations apply during the beta:

* Only the `operationsWorkbench` surface is supported. A producer portal surface is planned; authoring it currently has no effect.
* The following are not supported yet:
  * Data type editors and overviews
  * Display configuration for coverages, policy lines, and exposure groups
  * Account create dialogs

Other limitations are noted on the relevant pages within the [configuration guide](/configuration/configurable-ui/overview).

Next Steps [#next-steps]

* [Configurable UI Overview](/configuration/configurable-ui/overview)
* [Configurable UI Tutorial](/learning/configurable-ui/overview)

See Also [#see-also]

* [Configuration Deployment](/configuration/general-topics/deployment)
* [Data Extensions](/configuration/data-extensions/overview)
* [Automation Plugin](/configuration/plugins/automation)
