Overview

This article sets the naming standards for all names and system names in the Clio Operate solution. It replaces the earlier Naming Conventions article.

Names and system names

A standardised naming convention is the bedrock of a searchable, scalable workspace. It keeps configuration consistent across teams and prevents the duplicate clutter that affects growing operations.

Kebab-case is the mandated format for most system names. This format protects your configuration during imports from core environments. All non-core configuration must use the triple-tier prefixing strategy described below.

The 'custom' global prefix

All user-defined configuration must begin with the custom- prefix. The prefix serves two functions:

• Identification: it distinguishes bespoke settings from out-of-the-box core features at a glance.
• Overwrite protection: it prevents your configuration from being overwritten or corrupted when core configuration packages are imported or updated from a master environment.

Core configuration carries the matching core- prefix, for example core-approval-fees. Never use the core- prefix for your own configuration.

Functional context prefix

After the global prefix, you must apply a second identifier that defines the work type or context.

• Context specific: use the specific work type, for example family or commercial.
• Global or generic: use common for settings that apply across all business units.

Syntax examples

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

The system name must be entirely lowercase. It must contain no special characters other than hyphens, so that kebab-case integrity is maintained.

Common configuration items

The same three-tier pattern applies across the configuration items that implementations create most often.

Display names

The system name is not visible to end-users. The name is.

Where a configuration item carries the custom- system prefix, its name must also carry the Custom - prefix. The name then mirrors the elements of the system name, separated by spaced hyphens.

For example, the system name custom-family-vulnerable-person gives the name Custom - Family - Vulnerable Person.

Work types are exempt, because their system names do not carry the custom- prefix. See Work types below.

Configuration exclusions and special formats

The custom- kebab-case convention applies to most 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 derive from a structural path, they do not require the custom- prefix.

• Format: kebab-case, following the path from parent to child.
• Logic: [parent]-[sub-category]-[specific-type]
• Example: matter-dispute-claimant

Use only as many elements as the hierarchy needs. A root work type has a single element, for example matter, offer, or instruction. A first-level child adds one element, for example matter-dispute.

The name follows the same hierarchy in title case, with spaced hyphens between elements. For example, matter-dispute-claimant gives the name Matter - Dispute - Claimant.

Calculated fields

All calculated fields must use PascalCase. This format distinguishes dynamic logic from static data points. Anyone who audits the system or writes scripts can then identify a field as a calculation rather than a standard input.

• Format: PascalCase, with no spaces and every word capitalised.
• Naming convention: the name must be explicitly relevant to the mathematical or logical function of the field.
• Example: VulnerablePersonTotalVat or DisbursementSubTotal

In the calculated field editor, the field labelled Name holds the system name. The field labelled Display Name holds the name that end-users see.

Existing calculated fields in older environments use a mix of formats. Apply PascalCase to all new calculated fields, and check for a field that already does the same job before you create one.

Form Builder fields

Field names in Form Builder must use camelCase. Keep them as a concise, abbreviated version of the field title, so that they remain manageable in document automation and data mapping.

• Format: camelCase, with no spaces, a lowercase first word, and subsequent words capitalised.
• Naming convention: a brief, descriptive version of the display label.
• Example: where the field title is "Other Party Date of Birth", the system name is otherPartyDateOfBirth

Workflow variables

Variables and input parameters in the Workflow Modeller must use camelCase. Kebab-case is not valid here. The Identifier field accepts alphanumeric characters and underscores only, and it rejects hyphens.

In the variable editor, the field labelled Identifier holds the system name. The field labelled Display Name holds the name that end-users see.

A work type identifier stores the id of a work item that you have created, or of the work item that triggered the plan. An ODS, participant, or participant role variable stores the id of a team, organisation, or person. That id can come from a Data Composer function or from an allocation rule. A call to action variable stores the information for a button placed on a checklist item.

Where a workflow holds several tasks, name each task id variable after the task that it refers to.

An identifier cannot begin with a digit. Where the display name begins with a number, prefix the identifier with an underscore. For example, the display name "3 Months From Now Date" gives the identifier _3MonthsFromNowDate.

Do not prefix the identifier with the data type. The variable editor records the type in the Data Type field.

Workflow plan and step names

Plan system names

A consistent convention makes plans easy to find, and makes the configuration understandable to other people.

Clio recommends the format custom-{worktype}-{path indicator}-{sequence}-{name}.

• Work type indicates the type of work, for example matter, instruction, or offer.
• Path indicator describes where the work type sits in the work type hierarchy.
• Sequence is the sequence number for this workflow in terms of execution.
• Name is the individual name for the workflow. For a workflow triggered on a phase change, use the phase name.

For example:

custom-matter-dispute-defendant-001-investigation
custom-offer-made-calderbank-002-expired

Plan names

The plan name mirrors the plan system name. Use title case, and separate each element with a spaced hyphen.

For example, custom-matter-dispute-defendant-001-investigation gives the name Custom - Matter - Dispute - Defendant - 001 - Investigation.

Step names

Step names vary with the function of the step. Use the most descriptive name that you can, and prefix the name with a descriptor that states the primary purpose of the step.

For example:

• Task: Initial investigation
• Change Phase: Move matter to Litigation
• Key Date: Set discovery due date

Action plan checklist item wording

Checklist items in an action plan are visible to end-users, so consistent wording helps them recognise what each item asks for. A single-word indicator, used consistently across common types of item, gives end-users that consistency.

You can adopt your own standards. The following are the standards that Clio Operate uses.

Superseded conventions

The conventions below applied under the earlier Naming Conventions article. Configuration built before this article was published can still use them. Apply the current standard to all new configuration.