Overview

This document establishes best-practice standards and configuration protocols for all names & system names within the Clio Operate solution.

Names and System Names

Establishing a standardised naming convention in Clio Operate is the bedrock of a searchable, scalable workspace. It ensures that data remains consistent across teams and prevents the "duplicate clutter" that often plagues growing operations.

To ensure long-term stability and prevent data loss during configuration imports from core environments, kebab-case is the mandated format for most System Names. All non-core configurations must adhere to a triple-tier prefixing strategy.

The 'custom' Global Prefix

All user-defined configurations must begin with the custom- prefix. This serves two vital functions:

• Identification: It distinguishes bespoke settings from "out-of-the-box" core features at a glance.
• Overwrite Protection: It prevents your unique configurations from being overwritten or corrupted if core configuration packages are imported or updated from a master environment.

Functional Context Prefix

Following the global prefix, a secondary identifier must be applied to define the Work Type or Context.

• Context Specific: Use the specific work type (e.g., family, commercial).
• Global/Generic: Use common for settings that apply across all business units.

Syntax Examples

The resulting string follows a [origin]-[context]-[description] hierarchy:

Note: Always ensure the System Name is entirely lowercase and contains no special characters other than hyphens to maintain kebab-case integrity.

Configuration Exclusions & Special Formats

While the custom- kebab-case convention applies to the majority of the environment, the following entities are exempt to align with structural hierarchy and functional logic.

Work Types

Work Type system names must reflect their exact position within the work type hierarchy. Because these names are derived from a structural path, they do not require the custom- prefix.

• Format: kebab-case (following the parent-to-child path).
• Logic: [Parent]-[Sub-Category]-[Specific-Type]
• Example: matter-dispute-claimant

Calculated Fields

To distinguish dynamic logic from static data points, all Calculated Fields must utilise PascalCase. This ensures that anyone auditing the system or writing scripts can immediately identify a field as a "calculation" rather than a standard input.

• Format: PascalCase (No spaces, every word capitalised).
• Naming Convention: Names must be explicitly relevant to the field's mathematical or logical function.
• Example: VulnerablePersonTotalVat or DisbursementSubTotal

Form Builder Fields

Field names within the Form Builder should utilise camelCase. These should be a concise, abbreviated version of the "Field Title" to ensure they remain manageable when used in document automation or data mapping.

• Format: camelCase (No spaces, first word lowercase, subsequent words capitalised).
• Naming Convention: A brief, descriptive version of the display label.
• Example: If the field title is "Other Party Date of Birth," the system name should be: otherPartyDateOfBirth