Every datastore field, regardless of type, shares a common set of settings displayed at the top of the New Datastore Field dialog. These appear before the type-specific options, and understanding them once makes every subsequent field much faster to configure.
Row Name (Required)
The name of the column in the database table. Constraints:
- Must be lowercase.
- Alphanumeric, no spaces.
- Can include underscores but the platform convention is to avoid them.
- Must be unique within the datastore (you can't have two fields with the same Row Name).
The Row Name is used in raw SQL, in API responses, in ##AMDATA_rowname## merge tokens within templates, and as the column name on the underlying MySQL table. Once chosen, renaming is possible but disruptive — any external integration, custom code, or template that references the old name will need updating.
Friendly Name (Required)
The user-facing label displayed above the field on every form, list, detail page, and email merge token. Use proper case and natural language:
- Good: "Company Name", "Contact Email", "Date of Birth".
- Bad: "company_name", "CONTACT EMAIL", "dob".
The Friendly Name is what users see, so it should read naturally. If you ever struggle to pick one, ask yourself "what would I call this field in a conversation?" — that's the right answer.
Description
Optional inline help text shown below the field on forms. Use it to clarify ambiguous fields ("Enter the customer's primary contact email"), explain validation rules ("Must be a valid VAT number with country prefix"), or warn about gotchas ("Once submitted this cannot be changed").
Description is heavily under-used. Most field labels are clear in isolation but ambiguous in context — a Description that says "this field is the customer's email, not the salesperson's" prevents an entire class of data-entry error.
Table View Width
How wide the column is when this field appears in a table layout (the data list, browse views, exports). Three kinds of valid value:
- Pixel value — e.g.
150px. Absolute width. - Percent value — e.g.
10%. Proportion of the table. - The keyword
hide— omits the field from all table displays.
Hiding is common for fields that exist on the row for backend use but shouldn't be shown to users — system flags, foreign-key IDs that get rendered as friendly names elsewhere, internal timestamps. Set Table View Width to hide and the field stays on the row without cluttering the list.
Edit View Width
The width of the input when the row is being edited. Same rules apply — pixel or percent value, or hide to omit the field from edit forms.
A common pattern: a field is editable only on create, not on subsequent edits. Set Edit View Width to hide and the field appears on the New form but not on the Edit form. Combine with a sensible Default Value for the create path.
Default Value
Pre-fills the field when creating a new row. Helpful for sensible defaults that reduce typing for users:
- Boolean fields: default to
1for "active",0for inactive flags. - Currency fields: default to
'GBP'or whatever your platform's primary currency is. - Country fields: default to the configured Site Settings → Default User Country.
- Status fields: default to whatever the initial status of a new row should be.
Default Value can also reference platform context — special tokens like {{currentUserID}} or {{today}} get substituted at row creation time.
Validation
Apply a named validation rule from the Validations list. Common rules built into the platform:
- Email format.
- URL format.
- UK postcode (and other country postcode formats).
- Regex match (you supply the pattern).
- Numeric range.
- Length range.
- Unique within the datastore.
For business-specific validation ("VAT number must match country prefix"), define a custom rule in the Validations admin and pick it here.
Required
If on, the field must have a value before the row can be saved. Inline error appears next to the field if it's missing. Required validation runs both client-side and server-side.
Three notes on Required:
- Required-when-visible: a field hidden by Conditional Form rules is treated as not-required while it's hidden, even if Required is on.
- Required is enforced on Edit too — if you mark a field Required on an existing row that doesn't have a value, the user has to fill it in before saving any edit.
- Required at the field-type level is independent of Required at the Stage Field level (in UIVs). Both layers can mark requiredness; the form respects whichever is stricter.
Encrypt
If on, the field's value is encrypted at rest using the platform's configured encryption engine (see Site Settings → Security). Use for sensitive data:
- Personal identifiable information (PII).
- Health records.
- Financial details.
- Tokens, keys, or credentials.
- Anything covered by a data-protection regulation.
Encrypted fields are transparent to authorised users — they read and write the field as normal, and the platform handles the encryption/decryption automatically. The performance cost is small but non-zero, so don't encrypt every field by default — only the ones where the protection genuinely matters.
Tip: Get into the habit of always filling in the Description even when the field seems self-explanatory. The platform's inline help is one of the cheapest forms of usability improvement — users who'd otherwise guess at meaning get a clear explanation instead.