Configuration Best Practice - Forms

Overview

This document outlines the configuration best practices for the Form Builder in Clio Operate. Adhering to these standards ensures system consistency, enhances data integrity, and improves the long-term maintainability of custom forms.

Form & Field Names & System Names

To maintain a scalable and organised environment, all form titles, field labels, and backend system names must strictly adhere to the established naming conventions.

Form Builder - Editor

Display Order

To ensure future-proofing and minimise administrative overhead, display orders must be spaced incrementally. This allows new fields to be added without requiring a bulk update of existing order values.

  • Recommended Approach: Utilise increments of 10 (e.g., Field 1 = 10, Field 2 = 20, Field 3 = 30).
  • Benefit: If a new field is required between existing positions 20 and 30, it can be assigned a value of 25 without disrupting the surrounding sequence.

Fields

Note: The following field attribute standards should be applied globally unless a specific business requirement dictates otherwise.

Option Set Picker

Attribute: allowNoSelection

  • Standard: Set to True.
  • Rationale: This configuration ensures the field remains null/blank upon initialisation. By preventing an automatic default to the first available value, users are required to make a conscious, intentional selection, thereby increasing data accuracy.

Text

Attribute: maxLength

  • Standard: Set to 100.
  • Rationale: Standardising character limits prevents excessive data entry while ensuring compatibility with standard UI layouts.

Memo

Attribute: richText

  • Standard: Set to False.
  • Rationale: Disabling rich text ensures seamless compatibility with the Data Composer and document tagging features, avoiding potential formatting conflicts during document generation.

Attribute: maxLength

  • Standard: Set to 1000.

Attribute: rows

  • Standard: Set to 5.
  • Rationale: Provides an optimal visual footprint on the form while offering sufficient space for descriptive input.

General

Yes/No or Choices with 2 Options

In scenarios requiring binary data capture (e.g., Yes/No), several field types are available. Selection should be based on the specific UI requirements and the need for mandatory input.

Boolean

  • UI Component: Checkbox.
  • Best Use: Ideal for simple acknowledgements or for triggering conditional display logic.
  • Considerations: This field lacks a "null" state; it must default to either "On" or "Off," meaning it cannot be used to force a conscious user decision.

Toggle

  • UI Component: Visual Toggle Switch.
  • Best Use: Provides a modern aesthetic for binary choices. Labels are customisable beyond a simple "Yes/No."
  • Considerations: Similar to the Boolean field, it defaults to a specific state, which may lead to passive data entry errors.

Option Set Picker

  • UI Component: Dropdown Menu.
  • Best Use: Recommended when a definitive choice is required.
  • Key Advantage: By utilising the allowNoSelection attribute, the field can default to blank, forcing the user to actively select an option rather than relying on a system default.