A Property ID is the unique identifier used to reference a component in logic, outputs, and API calls. Consistent naming makes modules easier to read, debug, and maintain. These conventions apply to all Module Builder components.
Core Rules
- Format: All Property IDs must use camelCase—lowercase first word, each subsequent word capitalized, no spaces (for example,
firstName,totalAmount). - No spaces or punctuation: Only letters and numbers.
- Never use periods (
.): Periods break dot notation in expressions and logic. - Avoid leading numbers: Use descriptive names, not sequential IDs.
Data Input Fields
Standard input fields do not use a component-type prefix. Use a descriptive name that represents the data the field stores.
Components: Text Field, Number, Dropdown, Radio, Checkbox, Hidden, Email, Date Input, and other basic input types.
| Good | Avoid |
|---|---|
lastName |
textfieldLastName |
monthlyIncome |
numberMonthlyIncome |
userEmail |
emailUserEmail |
dateOfBirth |
dateDateOfBirth |
Component-Type Prefixes
Operational, layout, and complex components use a required prefix followed by a descriptive name in camelCase, where 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 |
| Smart Grid | sg |
sgOrderHistory |
| 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/Map v2 | map |
mapStoreLocations |
AI Components
| Component | Prefix | Example |
|---|---|---|
| AI Agent | aiAgent |
aiAgentSupport |
| AI Summarizer | summarizer |
summarizerReport |
Why Naming Conventions Matter
Consistent Property IDs let you 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 full of calc, plug, dwf, and rule prefixes reads like a clear diagram.
It also makes 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 exact prefix conventions when generating Property IDs unless explicitly instructed. Consistency throughout a module matters more than strict adherence to any specific prefix—if the agent uses a different but consistent pattern, align manually or provide naming guidance in the prompt.
Changelog
| Date | Change |
|---|---|
| — | Initial publication. |