---
title: "Property ID Naming Conventions"
slug: "property-id-naming-conventions"
tags: ["reference-guides"]
status: "update"
updated: 2026-10-20T14:23:21Z
published: 2026-10-20T14:23:21Z
canonical: "docs.unqork.io/property-id-naming-conventions"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.unqork.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Property ID Naming Conventions

A Property ID is the unique identifier that logic, outputs, and API calls use to reference a component. Consistent naming makes modules easier to read, debug, and maintain. This guide covers the requirements the platform enforces and the naming conventions that apply to all Module Builder components.

## Platform Requirements

The Properties panel displays an inline message when a Property ID breaks one of these requirements. The platform also rejects a module that contains an invalid Property ID when Creators save it. Every Property ID must meet the following requirements:

- It is not empty.
- It begins with a letter or an underscore.
- It contains only letters, digits, hyphens, periods, and underscores.
- It is unique in the module.
- It is not `vars`, in any capitalization. The platform reserves this value.

| Message | Cause |
| --- | --- |
| Property ID is required | The Property ID is empty. |
| Property ID must start with a letter or underscore and may contain only letters, numbers, hyphens, periods, and underscores | The Property ID begins with a digit or contains a space or another punctuation character. |
| Property ID already in use | Another component in the module has the same Property ID. |
| Cannot use ‘vars’ as Property ID | The Property ID is reserved. |

## Naming Conventions

The platform accepts some Property ID formats that cause problems in logic and expressions, like periods. Follow these conventions for readable, predictable names:

- **Format**: Use camelCase, with a lowercase first word, each later word capitalized, and no spaces (for example, `firstName`, `totalAmount`).
- **Letters and digits only**: Avoid hyphens, underscores, and other punctuation, even where the platform accepts them.
- **No periods**: Periods break  in expressions and logic, even though the platform accepts them.
- **Minimal digits**: Use descriptive names instead of sequential IDs. Add digits only when sequencing requires them.

## Data Input Fields

Standard input fields do not use a component-type prefix. Use a descriptive name that represents the data the field stores. This applies to the Text Field, Number, Dropdown, Radio, Checkbox, Hidden, Email, and Date components, and other basic input components.

| Good | Avoid |
| --- | --- |
| `lastName` | `textfieldLastName` |
| `monthlyIncome` | `numberMonthlyIncome` |
| `userEmail` | `emailUserEmail` |
| `dateOfBirth` | `dateDateOfBirth` |

## Component-Type Prefixes

Operational, layout, and complex components use a prefix followed by a descriptive name in camelCase. The descriptive part begins with a capital letter.

### Logic and Data Processing

| Component | Prefix | Example |
| --- | --- | --- |
| Calculator | `calc` | `calcTotalAmount` |
| Data Table | `dt` | `dtStateList` |
| Data Workflow | `dwf` | `dwfFormatData` |
| Decisions | `rule` | `ruleCheckAge` |
| Initializer | `init` | `initOnLoad` |
| Plug-In | `plug` | `plugGetSubmissions` |
| Timer | `timer` | `timerSession` |

### Display and Layout

| Component | Prefix | Example |
| --- | --- | --- |
| Columns | `col` | `colUserInfo` |
| Content | `content` | `contentDisclaimer` |
| Field Group | `fg` | `fgAddressDetails` |
| HTML Element | `html` | `htmlWelcomeText` |
| Markdown | `md` | `mdResponse` |
| Navigation | `nav` | `navMain` |
| Panel | `panel` | `panelConfirmation` |
| Repeater | `rep` | `repLineItems` |
| View Grid | `grid` | `gridSubmissions` |

### Grids

| Component | Prefix | Example |
| --- | --- | --- |
| Advanced Datagrid | `adg` | `adgDependents` |
| Dynamic Grid | `dg` | `dgEmployees` |
| Freeform Grid | `ffg` | `ffgTaxData` |
| Uniform Grid | `ug` | `ugMetrics` |

### Actions and Inputs

| Component | Prefix | Example |
| --- | --- | --- |
| Button | `btn` | `btnSubmit` |
| File | `file` | `fileResume` |
| File Storage | `fs` | `fsAttachment` |
| Protected Field | `protected` | `protectedPassword` |
| Signature | `sign` | `signAgreement` |

### Charts and Visualization

| Component | Prefix | Example |
| --- | --- | --- |
| Chart | `chart` | `chartSales` |
| KPI | `kpi` | `kpiTotalRevenue` |
| Map and Map v2 | `map` | `mapStoreLocations` |

### AI Components

| Component | Prefix | Example |
| --- | --- | --- |
| AI Summarizer | `summarizer` | `summarizerReport` |

## Why Naming Conventions Matter

Consistent Property IDs let Creators identify a component's type and purpose at a glance. Naming consistency matters most when reading Initializer component outputs, Data Workflow component inputs, or troubleshooting a Plug-In component. A canvas where `calc`, `plug`, `dwf`, and `rule` prefixes identify each component is easier to follow.

Consistent names also make maintenance safer. Creators can identify every component that depends on a given Property ID before renaming or deleting it.

> [!NOTE]
> The Build Agent might not always follow these prefix conventions when it generates Property IDs, unless the prompt specifies them. Consistency throughout a module matters more than strict adherence to any specific prefix. If the agent uses a different but consistent pattern, align the names manually or include naming guidance in the prompt.

---

**Changelog**

| Date | Change |
| --- | --- |
| 2026-10-19 | Added the platform's Property ID requirements and separated them from the naming conventions. |
| 2026-03-30 | Initial publication. |

A Property ID is the unique field ID used by Unqork to track and link components in your module.

APIs (application programming interfaces) are a set of protocols and definitions developers use to build and integrate application software. APIs act as the connective tissue between products and services.

A definition

Debugging is the process of finding and resolving errors or bugs in an application. To debug an application in Unqork, use UNQENG tools in Express View.

Also known as Unqork Users, or Designer Users; is anyone who is inside the Unqork platform.

A naming convention for computer programming. Use camelCase for Property IDs, for example: newUser, lastName, & rdoButton.

The Number data type accepts integer or floating point values. The number data type does not use quotes around numerical values.

HTML (Hyper Text Markup Language) is the standard markup language for for achieving font, color, graphic, and hyperlink effects when creating web pages.

A quanitifiable measure of performance of a specific objective for a specified time.

A Property ID is the unique field ID used by Unqork to track and link components in your module.