Datastores

The ActiveManage development platform is built upon hundreds of datastores and other components. As you start to build an application on the platform, you will most likely create your own datastores to hold whatever data your business cares about — customers, orders, leave requests, asset records, calendar bookings. Almost every feature you'll configure ultimately reads from or writes to a datastore.

Datastores are very similar to database tables that you may have encountered previously. The crucial difference is that the platform wraps each table with a rich layer of metadata: friendly names, field types, validation rules, permission rules, audit-mode flags, row-level security, and more. Where a raw database table is just rows and columns, an ActiveManage datastore is rows and columns plus everything the platform needs to render forms, browse views, search results, and APIs around them without you writing custom code.

What a datastore brings beyond a database table

Standard database tables cannot be directly accessed from web browsers without certain software, and the field types supported within database tables are very minimal out-the-box — number, text, date. Datastores layer on:

• Over 50 customisable field types with full front-end UI components and server-side validation, ready to drop onto forms without any HTML/JavaScript work.
• Auto-generated New, Edit, View forms for every datastore. Add a field to the datastore and it appears on the form automatically.
• Auto-generated browse views for listing rows, with sortable columns, filters, search, pagination, and row actions.
• Built-in permissions at three levels — whole table, individual fields, individual rows — so different roles see different data.
• Built-in audit trail recording every change with who, when, and what changed (when audit mode is on).
• Soft-delete semantics so deleted rows can be recovered until they're hard-purged separately.
• Tenant scoping for multi-tenant deployments, so rows are automatically filtered by the current tenant.
• API exposure — every datastore is reachable via the platform's REST API with the same permission rules applied.

The standard set of row actions

Whenever you access a datastore, you will notice a standard set of actions that you can perform on each row, providing you have the required permissions:

• View — opens a read-only detail view of the row.
• Edit — opens the auto-generated edit form, pre-populated with the row's current values.
• Copy — duplicates the row into a new draft, ready to edit. Useful for templates or near-identical records.
• Delete — soft-deletes the row. Recoverable from the Trash.
• Audit History — shows every change to this row over time (if audit mode is on).

Where datastores live in the admin panel

The full list of datastores is at Architect Panel → Data → Datastores. Each row in the list shows:

• The internal datastore name (lowercase, with a leading dot for system tables that ship with the platform).
• The friendly name shown to admins and users.
• A row of action buttons — View Data (opens the data list), Table Designer (opens the field-management screen), Permissions (opens the permissions config), and a few utility actions for history and copy.

System vs. application datastores

Datastores whose internal name starts with a dot (.tables, .tabledata, .users, .adminpanel-items, and dozens more) are platform-shipped. They're the structural backbone of ActiveManage itself and shouldn't be edited directly — changes will be overwritten on the next platform update, and changes to the wrong column can break the platform's own behaviour.

Datastores without a leading dot are your own application's tables. These are yours to create, edit, rename, and delete as your application's data model evolves.

Tip: When you create a new datastore, you'll be tempted to name it after the singular thing it represents ("customer" rather than "customers"). The convention on the platform is plural, lowercase, no underscores or hyphens. So customers, orders, leaverequests. Stick with that and your tables blend in with the platform's conventions.

Creating a new datastore is the single most common action when building an application on ActiveManage. The actual click-through is fast — fewer than 30 seconds for a basic table — but a few of the configuration choices deserve thought because they're hard to change later.

From the Architect Panel, open Datastores and click the green New Datastore button in the top-right corner. The configuration form opens with a stack of fields, grouped into a basic block, advanced toggles, and per-environment settings.

Core settings

The four fields you'll fill in for every datastore:

• Datastore Name — the internal name used in SQL queries, code, and API URLs. Must be lowercase, no spaces, no leading dot (that's reserved for system tables). Stick to plural nouns: customers, orders, invoices, leaverequests.
• Friendly Name — the human-readable name shown to admins and end users. Use proper case and natural plurals: "Customers", "Orders", "Invoices", "Leave Requests".
• Name of Rows — optional. Customises the singular label used on action buttons ("New Customer" instead of "New Record", "New Invoice" instead of "New Record"). If left blank, "Record" is used. Always worth filling in — "New Customer" reads much more naturally than "New Record".
• Database Host — almost always the primary database. Only change this if you've set up External Databases.

Advanced settings

The next block of toggles controls how the datastore behaves at scale and across tenants:

• Application Initialisation Mode — controls whether this datastore is created automatically on new tenant onboarding. Set to 2 to copy the structure but no data; set to 4 to copy both structure and seed data.
• Tenant Shared Data — when on, all tenants see the same rows (useful for reference data like a country list). When off (the default), each tenant has its own.
• Audit Mode — record every insert/update/delete on this datastore. Recommended for any datastore holding important business data; the overhead is small and the benefit is huge when investigating issues.
• Row-Level Security — enable to grant or revoke access on a per-row basis. See the Permissions section for how this works.
• Template Engine — enable if this datastore stores templated documents/emails that need to be evaluated server-side with merge tokens substituted.
• Default Page — the page to redirect to when a user navigates to this datastore as a friendly URL.

Three real-world configurations

Example 1: A simple Customers table

Name: customers. Friendly Name: "Customers". Name of Rows: "Customer". Database Host: primary. App Init Mode: 4. Tenant Shared: off. Audit Mode: on. Row-Level Security: off (most users can see all customers; row-level access by salesperson handled in browse views).

Example 2: A reference lookup table for Countries

Name: countries. Friendly Name: "Countries". Name of Rows: "Country". App Init Mode: 4 (seed list copied to every tenant). Tenant Shared: on (every tenant uses the same country list, so why have N copies). Audit Mode: off (countries don't change often, audit isn't useful).

Example 3: A multi-tenant Bookings table

Name: bookings. Friendly Name: "Bookings". Name of Rows: "Booking". App Init Mode: 2 (structure only, each tenant fills their own). Tenant Shared: off. Audit Mode: on. Row-Level Security: on (each customer sees only their own bookings via owner-based row rules).

Save, then add fields

Save the datastore. The underlying MySQL table is created automatically. You'll then see a Fields admin section appear — that's where you add columns to your new datastore. The next article walks through adding fields.

Warning: Renaming a datastore after launch is possible but risky — the underlying MySQL table is renamed, which means any external integrations referencing the old name will break. Get the name right at creation time and stick with it.

Adding rows to a datastore is one of the simplest things a user does on the platform — but the form they fill in is auto-generated, and every field on that form comes from your datastore's configuration. Get the field set right and the form is intuitive; get it wrong and users will struggle.

In the top-right corner of each datastore you will see a green button to allow you to add a new row to the table. When you click this button, a popup will open to allow you to complete the editable fields and save the row to the datastore.

What the form looks like

The platform auto-generates the form based on the fields configured on the datastore. Each field is rendered according to its type:

• Text Boxes get single-line text inputs.
• Text Areas get multi-line text inputs.
• Dropdowns get select boxes (or searchable dropdowns for larger lists).
• Dates get date pickers.
• Date and Times get combined date + time pickers.
• File Uploads get file picker dialogs with drag-and-drop support.
• Tickboxes and Toggle Switches get checkbox or sliding-switch widgets.
• Signatures get a drawable canvas.
• … and so on for all 50+ field types.

Note: The name of the button may be different if the "Name of Rows" field within the datastore settings has been populated. On a datastore where Name of Rows is set to "Customer", the button reads "New Customer" rather than "New Record". It's a small touch but it makes the platform feel much more polished to end users.

Required fields

Fields marked Required must have a value before the row can be saved. Required validation runs both client-side (instant feedback as the user types or tabs out) and server-side (caught at save time even if a malicious user bypasses the client-side check). If a required field is empty, the form refuses to submit and highlights the failing field with an inline error.

Conditional fields

If the form has Conditional Forms or Custom Form Rules attached, some fields appear or disappear as the user fills in others. For example: a Status dropdown with options "Open / Closed / Declined" might reveal a Reason text area only when Declined is picked. The reveal happens instantly as the user changes the trigger field — no page reload needed.

Validation

Beyond required-ness, each field's Validation setting can reject specific values. Common validation rules:

• Email format — rejects strings that aren't valid email addresses.
• URL — rejects strings that aren't valid URLs.
• Postcode — rejects invalid UK postcodes (or whichever locale you configure).
• Regex match — rejects strings that don't match a custom pattern.
• Numeric range — rejects numbers outside a min/max bound.
• Unique — rejects values that already exist on another row in the same column.

Validation failures show inline next to the field. The row can't be saved until every error clears.

After saving

The popup closes and the new row appears in the datastore list. If the datastore has audit mode enabled, the creation is recorded in the audit log automatically — every change tracked with who, when, and what.

If the datastore has a trigger task or a post-insert callback configured (via custom code), it runs after save. Common post-insert actions:

• Send a notification email to relevant parties.
• Update a related row in another datastore (e.g. recalculate a total).
• Push the row to an external system via the API or a Table Sync.
• Generate a document from a template.

Tip: Test the New Record form with a representative user from each role that'll use it before declaring the datastore done. The auto-generated form is generally good, but field order, required-flag placement, and conditional logic can all need tuning based on how real users actually fill it in.

Once a datastore has rows, every row gets an action toolbar — typically including View, Edit, Copy, Delete, and an audit history button. Whether each action is available to a user depends on their permissions on the underlying datastore.

Edit and Delete are the two most heavily-used actions, and both deserve a clear understanding because misuse — particularly of Delete — can be hard to undo.

Edit

Clicking Edit opens the same form used for creating a row, pre-populated with the row's current values. The user changes whatever fields they want and clicks Save.

Behind the scenes:

• Validation runs again — required fields must still have values, validation rules still need to pass.
• Audit log records the change if audit mode is on. The before/after values for every modified field are captured.
• Post-update callbacks run after save — same hooks as post-insert.
• Triggers on the datastore fire if configured.

If audit mode is enabled, every change is recorded with the user, timestamp, and the field-level before/after values. That trail is visible from the row's Audit History button — useful for debugging "who changed this and when?".

Delete

The Delete button looks destructive but it isn't, by default. Delete is a soft delete — the row's MSTisdeleted column flips from 0 to 1 but the data remains in the database. Hidden from normal listings but recoverable from the Trash view.

Why soft delete instead of hard delete? Three reasons:

• Accident recovery. Most data is deleted by mistake. Soft delete gives you a one-click undo.
• Audit trails. Records survive long enough to satisfy compliance retention rules without admins having to remember to back up.
• Referential integrity. Other rows that reference the deleted row don't break — the linked row is still there, just flagged.

Note: Soft delete is platform-wide. Even rows you've "deleted" from a datastore are kept until a separate hard-delete operation (usually scheduled, or run by an admin) actually removes them. That's an important detail for compliance regimes that mandate true deletion of personal data — you need a hard-delete process on top of soft-delete to fully purge data.

Copy

The Copy action duplicates the row into a new draft, ready to edit. Useful for templates or near-identical records — a copy of last month's invoice, a re-run of a previous order, a near-duplicate customer record where most fields stay the same.

The new row gets a fresh ID and timestamps. Linked rows (e.g. line items on an order) are typically copied too if the datastore is configured for it, but check your specific datastore's behaviour — defaults vary.

Where the action toolbar appears

The full toolbar (View / Edit / Copy / Delete / Audit History) appears in three contexts:

1. The standard data list

Open the datastore via View Data and you see every row with its action buttons. This is the admin-side default.

2. Browse Views

Customisable end-user listings where you decide which actions appear. A browse view for customers might show only View and Edit; one for orders might add a custom "Mark as Shipped" action.

3. User-facing pages

When a row is exposed via a Friendly URL or embedded in a Page Builder page, the actions are typically pared down to just the ones relevant for the role consuming the page.

Permission requirements

Each action checks the user's permissions against the datastore:

• View requires Read.
• Edit requires Edit (which implicitly assumes Read).
• Copy requires both Read (to see the source) and Write (to create the copy).
• Delete requires Delete.
• Audit History requires Read.

Without the relevant permission, the corresponding button simply doesn't appear. That's a clean UX — users don't see buttons they can't use — but it can be confusing during debugging ("why isn't the Edit button there?"). The first thing to check when a button is missing is the user's permissions for that datastore.

ActiveManage never destroys data on a normal delete. Every datastore row has a MSTisdeleted column; deleting just flips it from 0 to 1. The row stays in the database, hidden from listings, recoverable. This is one of the platform's most defensive design choices and it has saved many an admin from a fat-fingered delete.

Why soft delete?

Three concrete reasons the platform defaults to soft delete:

1. Accident recovery

Most data is deleted by mistake — wrong row picked, wrong filter applied, wrong user clicked. Soft delete gives you a one-click undo: open the Trash, find the row, click Restore. Hard delete would mean restoring from backup, which is hours of work even when it goes well.

2. Audit trails

Records survive long enough to satisfy compliance retention rules without admins having to remember to back up. For industries with regulatory data-retention requirements (healthcare, financial services), soft delete is a free-rider on the platform's storage rather than a custom audit feature.

3. Referential integrity

Other rows that reference the deleted row don't break — the linked row is still there, just flagged. An order line that references a deleted product still resolves; the platform's queries filter out deleted rows from listings but the row itself is still queryable when needed.

Viewing the Trash

On most datastore lists there's a Trash button (or filter toggle) that flips the view between active rows and soft-deleted rows. Trash rows have an extra Restore action that flips MSTisdeleted back to 0.

The Trash view is permission-controlled separately from the main list. Typically only admins can see the Trash — regular users see only active rows and have no idea soft-deleted rows exist.

Three patterns for using soft delete well

Pattern 1: Auto-purge old soft-deletes

For datastores where the data is genuinely transient (logs, drafts, temporary records), keeping soft-deleted rows forever bloats the database. Set up a scheduled Task that hard-deletes rows where MSTisdeleted = 1 and the deletion timestamp is more than N days old. Common N values: 30 for low-importance data, 90 for moderate, 365 for compliance-bearing.

Pattern 2: Confirm-before-delete UX

The platform's default delete is a single click. For destructive actions on important data, configure a confirmation dialog. The Browse View configuration supports per-action confirmation messages.

Pattern 3: Soft-delete on cascade

When you delete a parent row, you often want to soft-delete its children too. Use a post-update trigger or a Custom PHP callback to cascade the MSTisdeleted flip down to related rows.

Permanent deletion

Truly removing a row from the database requires a hard delete. That's typically run from:

• The database admin tools directly (DBA opens a SQL client and runs DELETE).
• A custom admin page or row action you build for purging.
• A scheduled task that purges rows older than a configurable retention period.
• A GDPR-style "forget me" workflow that hard-deletes a specific user's data on request.

Warning: Hard delete is irreversible. If you have linked rows referring to the row you hard-delete, those references will be orphaned — queries that try to follow the link will return blank or error. Plan cascade behaviour before hard-deleting anything important.

Soft delete and external integrations

If an external system syncs with the datastore (via the API or Table Sync), they need to handle soft-delete somehow:

• Hidden from API by default — the platform's API filters out soft-deleted rows for most endpoints. External systems just see the row disappear.
• Explicit "include deleted" mode — some endpoints support a parameter to include soft-deleted rows. Useful for sync systems that want to mirror the platform's delete state.

GDPR and the right to be forgotten

Soft delete doesn't satisfy GDPR's right-to-erasure on its own — the data is still in the database, just flagged. To genuinely comply, build a hard-delete workflow that:

• Identifies all rows belonging to the requesting individual across all relevant datastores.
• Hard-deletes them (DELETE rather than UPDATE).
• Records the request and the deletion timestamp in a separate audit-only log so you can prove compliance.
• Cascades to related data as appropriate.

Manual entry doesn't scale. When you need to load hundreds, thousands, or hundreds of thousands of rows into a datastore, the import tools take over. The platform supports CSV, Excel, and other file types via a configurable importer.

The Import Data button on a datastore (next to the New Record button) opens the import dialog. You upload a file, map its columns to your datastore's fields, pick an import mode, and the platform processes the rows.

Import Type

The first decision the importer asks for is what kind of import you're doing:

Import All

Every row in your file becomes a new row in the datastore. Fast, but creates duplicates if the data is already there. Suitable for the very first load of a fresh datastore, or for cumulative logs where every imported row is intentionally new.

Import New Only

Checks an existing field (the Unique Key Field) and only adds rows whose unique value isn't already present. Useful for idempotent imports — you can re-run the same import multiple times without creating duplicates. Common for monthly sync files where each month's export overlaps with the previous.

Delete

Finds rows in the datastore whose Unique Key Field matches a value in the import file, and soft-deletes them. Useful for cleanup scripts: "here's a list of inactive customers; soft-delete them all". Combined with audit mode, it's a safe way to bulk-remove without losing the trail.

Unique Key Field

For Import New Only and Delete modes, you pick which column on the datastore is the unique identifier — the one used to match against the file's rows. Common choices:

• Email address for customer or user imports.
• SKU or product code for product imports.
• Reference number for order or transaction imports.
• External system ID for sync imports.

The Unique Key Field should be indexed in the database for performance. The platform usually creates an index automatically when you flag a field as Unique, but check for very large imports.

Column mapping

After uploading the file the importer shows a side-by-side mapper: file columns on the left, datastore fields on the right. For each source column, pick the destination field. Any column you don't map is ignored.

The importer auto-suggests mappings where the file's column header matches a datastore field's row name (or friendly name). Always review the suggestions — column header text can drift between exports, and one wrong mapping can corrupt thousands of rows.

Validation runs at row level

Each row is validated against the datastore's field rules — required fields, type rules, validation rules. If a row fails, the importer reports it and skips that row; the rest of the import continues.

At the end, the importer shows a report listing what succeeded and what didn't, with per-row failure reasons. You can then fix the offending rows in the source file and re-import — Import New Only mode means the already-imported rows won't be duplicated.

Three real-world import scenarios

Scenario 1: Initial customer migration

You're moving from an old system. Export all customers as CSV, upload, map columns to the new datastore's fields. Mode: Import All. Unique Key not needed.

Scenario 2: Monthly product sync

Supplier emails a monthly product list. Some products are new, some are updates to existing ones. Mode: Import New Only. Unique Key: SKU.

Scenario 3: Bulk archive of inactive accounts

Generate a list of accounts that haven't logged in for over a year. Mode: Delete. Unique Key: email. After import, run a verification report to confirm the expected count was deleted.

Tip: Always test imports on a small sample first. Take 10 rows from your source file, run them through the importer, verify the result. Only run the full import once you've confirmed the mappings and validation behaviour are right.

Datastore-level permissions decide whether a security group can see or write to a table at all. Field permissions go one level deeper — they let you hide or read-only certain columns for certain groups while keeping the rest of the table accessible. This is one of the most useful tools in the platform's permission toolkit because it means one datastore can serve multiple roles with different visibility, without cloning data.

Why field permissions matter

A real-world example. HR keeps a Staff datastore that has columns for:

• Public info: name, email, photo, job title.
• Management info: department, manager, start date, role grade.
• Compensation: salary, bonus, benefits package.
• HR-only: performance ratings, disciplinary notes, exit interview notes.

Without field permissions you'd need three or four separate datastores, each holding the appropriate subset, plus glue code to keep them in sync. With field permissions, one datastore serves them all — HR sees everything, line managers see the management info, sales reps see only the public subset, customers see nothing.

How to configure them

Open the datastore in the Architect Panel and click the Permissions button. The dialog has tabs for datastore-level permissions and for field permissions. Switch to the Field Permissions tab.

The matrix shows every field of the datastore down one axis and every security group across the other. Each cell has a dropdown with three options:

• Read — can see the field's value.
• Write — can set the value on new rows.
• Edit — can change the value on existing rows.

(In practice you'll often grant Read+Write+Edit together, or just Read, depending on the field's intended use.)

Defaults and inheritance

If a security group doesn't have an explicit field-permission row, it inherits the datastore-level permission for that field. So you only need to add field-permission rows where you want to differ from the datastore default.

That's a huge efficiency gain. A datastore with 20 fields and 10 groups has 200 possible combinations, but you'll usually have under 20 actual field-permission rows — covering only the exceptions.

Where field permissions take effect

Permissions are applied consistently across every surface the data is rendered on:

1. Auto-generated forms

Fields without read access don't appear in the New or Edit form. Fields with read-only access (read but not write) appear but are disabled. Fields with no access at all aren't even rendered into the page HTML.

2. Browse views and data lists

Restricted fields are stripped from the column list before render. A user who can read fields A, B, D sees columns A, B, D in their browse view; field C is silently omitted.

3. The API

API calls from a user without read access to a field get back the row with that field omitted from the response. Same rules — the missing field isn't error-flagged, it just isn't there.

4. Email templates and document templates

Merge tokens for restricted fields render as empty strings. So if you accidentally embed ##AMDATA_salary## in a template that's sent to non-HR recipients, they just see a blank space rather than the actual value.

Three real-world examples

Example 1: Salary field on a Staff table

Datastore-level default for HR: Read+Write+Edit. Override entries:

• Direct Managers group → Read only on the Salary field.
• All Other Staff → No Access on the Salary field.

Example 2: Internal Notes field on a Customer table

Datastore-level default: Read for All Users (everyone needs to see customer details). Override entries:

• Customer Success Team → Read+Write+Edit on Internal Notes.
• Everyone else → No Access on Internal Notes.

Example 3: Edit-only-by-status field on a Ticket table

The Status field on a Tickets table. Datastore-level default: Read for All Users. Override entries:

• Customer Service Team → Read+Write+Edit on Status.
• Everyone else (including the requester) → Read only.

Note: Field permissions don't affect SQL queries written in Custom Query Views or in raw PHP. If you're hand-coding access, you're responsible for applying the same restrictions in your query. The platform applies field permissions at the auto-generated form and API layer; bypassing those layers bypasses the permission too.

Inside any datastore, the Architect Panel exposes a Fields admin where you can add, edit, and reorder columns. Adding a new field is where you make most of your day-to-day configuration decisions — every new piece of business data is a new field, and the right Field Type choice affects how every form, every list, every export will look forever after.

Open the Fields admin

From the datastore list, click into a datastore to see its rows, then look for the Fields button or Table Designer button at the top. You'll see the existing columns listed in display order, each with their type and required-flag visible.

Click "New Datastore Field"

A dialog opens with a stack of common fields visible at the top of the form, plus a Field Type dropdown that drives everything below it.

The common fields (visible regardless of type)

• Row Name (Required) — the name of the column in the database table. Lowercase, no spaces, no special characters. Examples: companyname, contactemail, orderdate.
• Friendly Name (Required) — the title displayed to users above the field. "Company Name", "Contact Email", "Order Date".
• Description — text shown below the field as inline help. Use it to clarify ambiguous fields or explain validation rules.
• Field Type (Required) — pick from over 50 supported types. The dialog expands once you pick to show type-specific configuration.
• Table View Width — width of the field when shown in a table format. Enter a pixel value like 150px, a percent like 10%, or the keyword hide to omit the field from table views.
• Edit View Width — width of the field when editing the data. Same rules apply. Enter hide to omit it from edit dialogs.
• Default Value — pre-populated value when a new row is created.
• Validation — apply a named validation rule from the Validations admin.
• Required — when on, the field must have a value before the row can be saved.
• Encrypt — when on, the field's value is encrypted at rest using the platform's configured encryption engine.

Type-specific options appear conditionally

The instant you pick a Field Type, the dialog grows to reveal options specific to that type. The conditional reveal is one of the platform's most-used patterns — it keeps the form short by hiding fields that don't apply.

A few examples:

• Number reveals Allow Decimals, Min/Max Value, and Units.
• Dropdown Box (Searchable) (DB) reveals Data Source, Option Sorting, Display Format, Parent ID Field, AJAX Mode, and many more.
• File Upload reveals Storage Mode, File Types, Default Library, Max Number of Files, Resize Uploaded Images, Generate Thumbnails.
• Text Box reveals Min Length, Max Length, Only Allow Unique Values, Provide Suggestions.

Read the dedicated article for the field type you've picked under the Datastore Field Types section. Those articles list every conditional option that appears when you pick the type, with concrete advice on how to set each.

Saving the field

Save and the field is added to the underlying database table immediately. The platform runs an ALTER TABLE to create the new column, plus inserts a corresponding row in .tabledata with the field's metadata.

The field is now available:

• On the auto-generated New and Edit forms.
• On any browse view that lists the datastore (subject to your width setting).
• As a column on the data list.
• As a merge token ##AMDATA_rowname## in any template that references the row.
• On the API in JSON responses.

Reordering fields

Reorder by dragging in the field list. Field order affects the display order on the auto-generated form and on the data list (left to right). For complex datastores, spend a moment thinking about logical field grouping — name and contact together, then dates, then financial data, etc. A well-ordered form is much faster to fill in.

Tip: Each field type has its own dedicated documentation page under the Datastore Field Types section. Read the page for the type you've chosen — those pages list every conditional option that appears when you pick the type and give concrete advice on how to configure each.

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 1 for "active", 0 for 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.