Naming Conventions¶

Established naming conventions for form items, forms, and related artefacts in the Versaa/LHP platform.

Form Names¶

Use clear, readable names (e.g., Component Replacement Request, Building Safety Check).
Prefix your own forms with your initials to distinguish them from inherited forms (e.g., IS_Family_Survey for Imran Saleem).
No spaces in the form technical name — use underscores or PascalCase.
The display name (caption) shown to users can have spaces.

Form Item Names¶

Underscores, no spaces¶

Form item names must use underscores. Spaces in names break Versaa — they cause JavaScript errors in any formula that references that field.

✅ Date_Of_Birth
✅ QL_Username_1
❌ Date Of Birth    ← breaks formula references

Data-source prefix¶

Prefix each form item name with a short code indicating where its data comes from:

Prefix	Source
`QL_`	Data pulled from Aareon QL (housing management system)
`CRM_`	Data from or written to the CRM
`SBE_`	Self-serve / back-end staging data
`z_`	Temporary / debug field — not saved to the Data Warehouse

Examples: QL_Username_1, CRM_ClientId, z_DebugToggle

PascalCase after the prefix¶

After the prefix and underscore, use PascalCase for each word:

QL_PropertyReference   ✅
QL_property_reference  ❌ (inconsistent style)

Numbered suffixes for multiples¶

If a form has multiple instances of a data type (e.g., two username fields), append a number:

QL_Username_1
QL_Username_2

Caption vs Name¶

Property	Purpose	Rules
Name	Internal identifier used in formulas and XML	Underscores only, no spaces, case-sensitive
Caption	Display label shown to the user	Can have spaces, human-readable

Always set both. When you copy a field, update both name and caption to reflect the new purpose.

A useful development trick: include the field type in the caption to make it obvious during development: - "Age [int]" → user sees "Age [int]", developer instantly knows it's an integer field - "Notes [txt]" → developer knows it's a text/string field

This is particularly useful because integer and string fields look identical in the form UI.

Packages (.ftpackage files)¶

Use descriptive, action-oriented names that identify the form, the change, and optionally the date:

component_replacement_request_other_button_27042026.ftpackage
hiding_employment_tenancy_check_v66.ftpackage
building_safety_check_debugger_fix_05052026.ftpackage

Avoid vague names like test.ftpackage or myPackage.ftpackage.

Workflows¶

Workflow names should match the form they serve, with a suffix for the type:

Component Replacement Request.PCACompletion   ← triggered on form complete
Client Visit.PCACompletion

Workflow variable names follow the same underscore/PascalCase convention as form items.

Reference Data¶

Reference data items use the same underscore convention. For colon-separated list values, the individual options are written without spaces:

Other:Use table value:Component not listed