Datastore Field Types

When you add a field to a datastore, the Field Type dropdown lists over 50 supported types. Each one renders differently, accepts different conditional options, and stores its value in a different way. Use this article as the quick-reference map; each type has its own dedicated article in this section.

Text input

• Text Box — single-line text.
• Text Area — multi-line text.
• Code Editor — text input with syntax highlighting.
• WYSIWYG Editor — rich-text editor.
• Password — masked input.
• Phone Number — international phone-number input with country picker.
• Random Alphanumeric String — auto-generated string of a chosen length.

Numbers, dates, time

• Number — integer or decimal with optional Min/Max/Units.
• Slider — numeric slider with Min/Max/Increment.
• Date, Date and Time, Time — date/time pickers.
• Colour — colour picker.

Selection

• Tickbox (Single) — single checkbox.
• Tickbox (Multiple) (Manual) / (DB) — multi-select checkboxes from a manual list or DB-driven list.
• Toggle Switch — single yes/no toggle.
• Radios — radio buttons from a manual list.
• Pills — selectable pills with custom CSS.
• Dropdown Box — Single/Manual, Single/DB, Searchable/DB, Multiple-Linked/DB.

Files and media

• File Upload — full-featured uploader with image resizing and library access.
• File Store Selection — pick existing files from a configured file store.
• Signature — capture a drawn signature.
• Screen/Media Recorder — record screen, webcam, or audio.
• Image Plotter — annotate or plot points on an image.
• Web Video — embed video from a hosting provider.

Location and contact

• Postal Address — multi-field address with optional Google Places autocomplete.
• Geolocation — capture latitude/longitude.
• Credit/Debit Card — PCI-compliant card input.

Lookups and search

• AJAX Search (DB) / (URL) / (Active Directory) — type-ahead search against different data sources.
• Active Directory Object — pick an AD user, group, or computer.
• User Search — type-ahead user picker.

Form structure and conditional logic

• Conditional Form, Dynamic Conditional Form — fields whose options each reveal their own sub-fields.
• Dynamic Add/Remove Field — repeatable field group with add/remove controls.
• Line Item Builder — repeatable row builder for line items.

Display and custom

• Icon, Icon Select — icon-only display, or single/multi icon picker.
• SQL Query, Custom, Custom PHP Code — execute SQL/HTML/PHP at render time.
• Audit Link — link to row history.
• Hidden, Special Hidden — invisible fields with stored values.
• Dummy Field — placeholder used by conditional forms.

The Text Box is the workhorse single-line text input. Use it for names, short titles, codes, reference numbers, and anything that fits on one line.

Conditional options

• Min Length — the minimum number of characters required. Leave blank for no minimum.
• Max Length — the maximum number of characters allowed. Leave blank for no maximum (the underlying database column still has a limit based on its type — usually 255 characters for VARCHAR).
• Only Allow Unique Values — when on, the form rejects values that already exist in this column on another row.
• Provide Suggestions — when on, as the form field is typed into, it will search the database for any entries similar and provide them as suggestions. Useful for fields like "Department" or "Job Title" where consistent vocabulary matters.

When to pick Text Box vs. Text Area

Text Box is for things shorter than about 100 characters that don't need line breaks. Text Area is for anything longer or anything where line breaks are part of the content (notes, descriptions, paragraphs).

The Text Area is a multi-line text input — exactly what HTML's <textarea> renders. Use it for free-form text where users might want to type a paragraph, a note, or a longer description.

Conditional options

• Min Length — minimum characters required.
• Max Length — maximum characters allowed.
• Height (px) — the rendered height of the textarea, in pixels. Defaults to the browser default. Common sensible values: 80px for short notes, 200px for longer descriptions.

For rich text, use WYSIWYG

The Text Area field stores plain text. If you need bold, italics, lists, or other formatting, pick the WYSIWYG Editor field type instead — it renders a rich-text toolbar and stores the result as HTML.

The Code Editor field renders a syntax-highlighted code editor — the same Ace-style editor used throughout the rest of the platform's IDE. Use it for fields that hold code, configuration files, structured templates, or SQL.

Conditional options

• Editor Theme (Required) — visual theme for the editor (light, dark, high-contrast, etc.).
• Code Language (Required) — pick the language so the editor highlights syntax correctly. Supported languages include PHP, JavaScript, HTML, CSS, SQL, JSON, YAML, Markdown, XML, and more.

How the value is stored

Plain text — the editor doesn't add any wrapping or encoding. Whatever you type ends up in the database column unchanged. Length limits depend on the underlying column type; for long code blocks make sure the column is at least MEDIUMTEXT.

Tip: Code Editor fields are perfect for letting non-developer admins configure things like email-template HTML or custom report SQL with proper syntax help and bracket matching, without giving them the whole IDE.

The WYSIWYG (What You See Is What You Get) Editor is the rich-text input — bold, italic, lists, links, images, tables, all controlled from a toolbar. Use it anywhere users need to compose formatted content: email body, page content, article HTML.

Conditional options

• Editor Features (Required) — pick which toolbar features to expose. The full feature list is long; common choices are Basic (bold, italic, lists, links), Standard (adds images, tables, colours), and Full (adds source code view and advanced media). Restricting features keeps editing focused and prevents users pasting unwanted styles.

What gets stored

HTML — the editor outputs standard tags. The platform renders that HTML wherever the field is displayed (subject to sanitisation rules on the public docs/site).

Reusing email designs

For email body fields specifically, consider pairing the WYSIWYG with an E-mail Design chosen via a related field — the design supplies the wrapper layout (header, footer, colours), and the WYSIWYG fills in the content area.

The Date field renders a calendar date picker. There are no conditional options — Date is one of the simplest field types.

How it's stored

As a SQL DATE value. The displayed format is controlled by the Date Display Format setting in Site Settings, so changing the format updates every Date field across your application at once.

Date vs. Date and Time

Pick Date when only the day matters (birthdates, leave dates, anniversaries). Pick Date and Time when the time of day matters (appointments, log entries, deadlines).

Note: A Date field stored without a time always has midnight as its implicit time, which can be surprising when joining against Date and Time fields. Use the SQL DATE() function to normalise both sides of a comparison.

The Date and Time field renders a combined date and time picker. The user picks a date from the calendar and a time from the time selector. No type-specific configuration options.

Display format

Controlled centrally in Site Settings under Date/Time:

• Date & Time Display Format — used everywhere this field type is rendered.
• Date & Time (incl. Seconds) Display Format — used in audit logs and other places where second-level precision matters.

Time zone

Stored values are in the server's configured time zone (set via $AMtimeZone in your config, normally aligned with the Site Settings Time Zone). If your application has users across multiple time zones, the rendered time reflects the server time zone — handle per-user conversion in your business logic if needed.

The Time field captures a time-of-day independent of any date. Use it for fields like shop opening hours, alarm times, or any recurring schedule slot.

Conditional options

None — the Time field has no type-specific configuration.

Storage and format

Stored as a SQL TIME value. Display format follows the time portion of the Site Settings Date & Time Display Format.

The Number field captures numeric values. It supports integers, decimals, optional min/max bounds, and an optional Units selector for when a value can be entered in different units (e.g. grams vs. kilograms).

Conditional options

• Allow Decimals? (Required) — when off, only whole numbers are accepted; when on, the field accepts decimal values (number of decimal places is configurable in the specialfeature).
• Minimum Value — optional lower bound.
• Maximum Value — optional upper bound.
• Units — if you would like to offer multiple types of units to select from when inputting a value (i.e. mg, g, kg) then please enter them here — one per line. The user picks a unit from a dropdown alongside the number input; conversion to a canonical unit is up to your business logic.

Stored value

Decimals are stored in the database column as a DECIMAL or DOUBLE (depending on the configured precision). Min/Max constraints are validated client-side and server-side — both must pass for the row to save.

The Slider field is a horizontal-slider input for numeric values. Use it where the range is fixed and small enough that a slider is more intuitive than a number input — for example rating fields (1–5) or security level pickers (1–3).

Conditional options

• Minimum Value (Required) — lower bound of the slider.
• Maximum Value (Required) — upper bound.
• Increment — the step size between two adjacent positions on the slider. Defaults to 1. Use a smaller value for finer-grained pickers (e.g. 0.5 for half-steps).
• Default Value — the position the slider starts at when the form opens for a new row.

Where Slider is used by the platform itself

The User Input View's Security Level setting is a Slider (Min 1, Max 3, Increment 1) — the three values map to the three security tiers described in the User Input Views section.

The Colour field is a simple HTML colour picker. The user picks a colour, the platform stores it as a hex string (e.g. #0d6efd) in the underlying database column.

Conditional options

None.

Common uses

• Theming / branding fields on a tenant or instance config.
• Status colours on a workflow.
• Calendar event colours.
• Per-row highlight colours in browse views (paired with the Colour Field option on a Dropdown's source data).

Rendering colour values elsewhere

The stored hex string can be referenced in CSS or HTML templates using the standard ##AMDATA_rowname## merge token — e.g. style="background-color: ##AMDATA_themecolour##".

A single checkbox — the user ticks or unticks. Stored as 0 (unticked) or 1 (ticked) in the database.

Conditional options

• Optional HTML/text to be shown above the checkbox — useful for an agreement statement ("I have read and agree to the following terms…"). Accepts HTML.
• Force User to Check The Checkbox? — when enabled, the user will be unable to submit the form until the box is checked. This is useful for user agreements etc.
• Optional HTML/text to be shown next to the checkbox — inline label rendered right of the checkbox itself ("I agree", "Receive emails", etc.).

Use cases

• Terms-and-conditions agreement (force-check).
• Email-opt-in flag.
• Active / inactive toggle (though Toggle Switch is often a nicer UX).

Render a group of checkboxes from a manually-entered list of options. The user can tick any combination; the field stores their selections together.

Conditional options

• Options — please enter one option per line. The displayed labels are exactly what you type; the stored values are the same strings.

When to use it

For short, fixed lists where the options will rarely change. Examples: notification preferences (Email, SMS, Push), allergens (Gluten, Dairy, Nuts), service-level perks (Priority Support, Onboarding Call, Dedicated Manager).

When NOT to use it

If your options come from a datastore (so they can be edited by admins without code changes), pick Tickbox (Multiple) (DB) instead. If you need labels and values to differ, also pick a DB-backed type.

Multiple checkboxes whose options are pulled live from a datastore. Edit the source table and the checkboxes update without redeploying anything.

Conditional options

• Data Source — which datastore the options come from. Pick the table and (typically) the field whose value will be shown.
• Option Filter (Required) — narrow the source rows by criteria (e.g. only rows where active = 1).
• Field to Group By — if the source table has a grouping field, options will be grouped under headings rather than listed flat.
• Display Format — if you would like the value to be displayed in a different format or include additional fields then please enter the format here. ##AMDATA_**## will be replaced with a field from the database row (replace ** with the field name).
• Option Sorting (Required) — Alphabetically A-Z, Alphabetically Z-A, or By Field. If you pick By Field, an additional Sort Field Name input appears.

How the value is stored

As a comma-separated list of the source rows' IDs (or chosen unique key). Joining back to the source on read is automatic for templates and merge tokens.

A modern on/off toggle. Behaves identically to a Tickbox (Single) — stored as 0 or 1 — but renders as a sliding switch rather than a square checkbox. The visual difference matters because users instinctively read switches as application settings and checkboxes as items to confirm.

Conditional options

None.

When to use Toggle Switch vs. Tickbox

• Toggle Switch — for ongoing settings ("Notifications: On", "Auto-Renew: On"). Reads as "is this state currently set?".
• Tickbox (Single) — for one-off acknowledgements ("I agree to the terms", "I have read this"). Reads as "have you completed this step?".

Single-select radio buttons rendered from a manual options list.

Conditional options

• Options (Required) — one option per line.
• Show Radio Options In-line? — when on, groups the radio options on the same horizontal row instead of stacking them vertically. Use for short option lists where horizontal saves space.

Radios vs. Dropdown vs. Pills

• Radios — best when the list is short (2–5 options) and the user benefits from seeing all options at once.
• Dropdown — best when the list is longer or screen real estate matters.
• Pills — best when you want a more visual / tactile UI with custom styling per option.

The Pills field renders each option as a clickable button ("pill") with custom styling. Pick single or multi-select; the CSS class applied when a pill is active is up to you. Great for tactile selection where you want stronger visual feedback than a dropdown.

Conditional options

• Item Size (Required) — the pills are based on a grid of 12. If for example, you select 4 for the item size, it will take up a third of a row in the grid.
• Display Mode (Required) — how pills are laid out (e.g. dropdown-style with text labels, icon-only, or both).
• CSS Class for Active (Required) — when one or more pills are selected, which CSS class would you like to apply to that item.
• On Click Function — the Javascript function that will be ran each time one of the pills is clicked.
• Icon Mode (Required) — whether to render an icon with each pill.
• Selection Mode (Required) — single-select or multi-select.

Where Pills are used by the platform

The User Input Views "Enable reCAPTCHA?" field uses Pills — four pills (No, v2 Checkbox, v2 Invisible, v3) with a grid space of 6 and a custom active CSS class.

A standard single-select dropdown where you supply the options manually.

Conditional options

• Options (Required) — please enter one option per line.

When to pick this vs. the DB-driven version

Pick Manual when:

• The list is short and stable (under 20 items).
• The list is unlikely to change often.
• No other datastore exists to source the options from.

Pick the DB-driven version (Dropdown Box (Single) (DB) or Searchable (DB)) when the options come from a table — that way admins can edit options without changing the field configuration.

Single-select dropdown whose options are pulled from a datastore. Use it whenever the option list belongs to an admin-editable table.

Conditional options

• Data Source — which datastore (and which field) the options come from.
• Field to Group By — if the source has a grouping column, options are grouped under headings.
• Option Sorting (Required) — Alphabetically (A-Z), Alphabetically (Z-A), or By Field. Picking By Field reveals a Sort Field Name input.
• onChange Code — a Javascript function you would like to run when a new option is selected. You can use e.currentTarget.id to get the field ID, e.params.args.data.id to get the option value and e.params.args.data.text to get the option text.
• Option Filter (Required) — narrows the source rows by criteria.
• Display Format — if you'd like the value displayed in a different format or with additional fields. ##AMDATA_**## tokens are replaced with field values from the source row.
• Only Fetch Own Records? — if ticked, only rows inserted into the linked table by the logged-in user will be shown in the dropdown list.
• Show Data from all Tenants? — if ticked, options from all tenants will be shown. Only applies if the user logged in has architect access.

When to pick Single (DB) vs. Searchable (DB)

Single (DB) renders a standard <select> — best when the option list is small. Searchable (DB) renders a type-ahead search box — best when the list is long (100+ options) or filtering by typing is faster than scrolling.

The Searchable (DB) dropdown adds a type-ahead search box on top of a DB-driven option list. It's the right pick for fields with more than around 50 possible options, or where the user knows what they want and finds typing faster than scrolling.

Conditional options

• Data Source — which table and field the options come from.
• Field to Group By — group options under headings.
• Option Sorting (Required) — A-Z, Z-A, or By Field (reveals a Sort Field Name input).
• onChange Code — Javascript run on selection. Use e.currentTarget.id, e.params.args.data.id, e.params.args.data.text.
• Option Filter (Required) — filter options by criteria.
• Display Format — control how each option is rendered. ##AMDATA_**## tokens are replaced with source-row field values. Example: ##AMDATA_firstname## ##AMDATA_lastname## (##AMDATA_email##).
• Only Fetch Own Records? — only options inserted by the logged-in user.
• Show Data from all Tenants? — pull options across all tenants (requires architect access).
• Parent ID Field — if you would like to show the options in a hierarchy tree, please enter the parent ID field name here. The table must contain at least 1 row with the value of 0 in the parent ID field.
• Option Enable Field — if you would like some options to be disabled, you can enter the field name within the source options table here. This works best with tickbox and toggle switch fields as 0 = disabled and 1 = enabled.
• Allow Multiple Selections (Required) — Yes for multi-select, No for single-select.
• Colour Field — if the source table contains a colour field, options will be shown in the specified colours per row.
• AJAX Mode (Required) — if there are a large amount of options within the dropdown field then you may experience better performance using AJAX to fetch the options. Picking AJAX Mode loads options on demand as the user types.

Hierarchy trees

Set Parent ID Field to render a tree. The platform expects rows whose Parent ID column is 0 to be top-level, and rows whose Parent ID points to another row's ID to be children. Users see expandable groups in the dropdown.

Configures a chain of dropdowns where each subsequent dropdown's options are filtered by the value of the previous one. Useful for cascading pickers — Country → Region → City; or Brand → Model → Trim.

Conditional options

• Data Source — picks the table that contains the linked dropdown definitions. Inside that source you define each dropdown in the chain, along with the join field that ties it to its parent.

How the chain renders

The first dropdown is populated unconditionally from its source. When the user picks an option, the second dropdown's source is filtered by the join field's value (e.g. only regions belonging to the chosen country), then populated. Each subsequent dropdown works the same way.

When to use it

Anywhere the value space is naturally hierarchical and the user benefits from progressively narrowing the choice. For free-form hierarchical picks (parent-of-parent-of), consider Dropdown Box (Searchable) (DB) with a Parent ID Field instead — it renders the hierarchy as a single tree.

The Icon field type is display-only — it renders an icon to the user but doesn't accept input. Use it when you want a visual cue on a list or detail page that's tied to a row's data, without giving the user something to click.

Conditional options

None.

Icon source

Defined by the row's underlying data — typically a separate field on the same row that stores the icon name or class. The Icon field renders whichever icon that row references.

Icon Select vs. Icon

For an interactive icon picker, use the Icon Select field type instead — it shows the icon palette and lets the user choose.

An interactive picker that lets the user choose an icon (single or multi-select). Useful for fields like "Category icon" or "Status icon" where the row needs a visual representation.

Conditional options

• Allow multiple selections? — when on, the user can pick multiple icons.
• Icon Type (Required) — which icon library/set the options come from (Font Awesome, custom upload, etc.).
• Grid Headers — if you would like the icons displaying in a grid format, please enter the headings for each column here, separated by a comma, otherwise leave this field blank.
• Grid Row Names — if you would like the icons displaying in a grid format, please enter the names for each row here, separated by a comma, otherwise leave this field blank.

Grid mode

Filling in Grid Headers and Grid Row Names renders the icon options as a labelled grid — useful when icons fall naturally into categories (e.g. communication icons in one column, navigation icons in another).

The File Upload field is the platform's most-configured field type. It handles uploads from the user, ties them to a File Store, and provides everything you need to control storage location, file-type restrictions, image processing, and lightbox display.

Conditional options

• Storage Mode (Required) — Internal (stored within ActiveManage's filestore) or External (the uploaded file will be stored on an external server).
• Storage Path — if Storage Mode is External, the full folder path (without trailing slash). Windows mapped network drive letters cannot be used, only full UNC paths or local physical drives.
• Default Library (Required) — which File Store the uploads land in by default.
• Files Allowed (Required) — which file types are accepted (Documents, Images, Videos, etc.).
• File Upload Method (Required) — "Allow New File Uploads and Library/Table Access" lets the user upload new files or pick existing ones from the library.
• Max Number of Files (Required) — limit how many files the user can attach to a single row.
• Enable Lightbox for Image Files — if this option is ticked, when viewing rows in a table images will be displayed in a lightbox when clicked, as opposed to being downloaded.
• Resize Uploaded Images? (Required) — automatically resize images to a configured maximum dimension on upload.
• Generate Thumbnails (Images Only) (Required) — pre-generate thumbnail versions for fast list rendering.

Behind the scenes

Uploaded files are stored according to the File Store's storage mode (local web server or AWS S3). The file metadata (filename, MIME type, size) is recorded in a related table, and the row in your datastore stores a JSON map of attached file IDs.

A picker that lets the user choose files from an existing File Store, with no upload capability. Use it where the row needs to reference files that are managed centrally — brand assets, document templates, standard photos, etc.

Conditional options

• File Store (Required) — pick the File Store the user can select from.
• Maximum Number of Files — the maximum number of files the user will be able to select from the file store for this field.
• Allowed File Types (Required) — narrows the picker to specific types so users don't see irrelevant files.

File Upload vs. File Store Selection

• File Upload — for user-uploaded files that may be unique per row.
• File Store Selection — for picking from a curated, admin-managed library.

Many forms use both: "Pick a logo from the brand library, or upload a custom one for this customer".

Capture a hand-drawn signature from the user. The field renders a canvas the user can sign on with mouse or touch input; the result is saved as an image attached to the row.

Conditional options

None.

Common uses

• Delivery confirmation.
• Consent and terms acceptance where a hand-drawn signature is preferred.
• Job-card sign-offs.

How the signature is stored

As a PNG image in the configured File Store. The datastore row holds the file's ID and metadata. The signature renders on any browse view or detail page that displays the row, and can be embedded in document templates for printable copies.

Capture audio, video, or screen recordings directly in the browser. The user clicks record, performs the action, stops, and the recording is attached to the row.

Conditional options

None at the field level — recording capabilities are controlled by the user's browser permissions.

Browser requirements

Modern Chromium, Firefox, or Safari builds. The user grants microphone, camera, or screen-share permission via the browser prompt when they click record.

Common uses

• Bug-report fields where users can demonstrate the issue.
• Voice-note responses on support tickets.
• Walkthrough recordings on user-input forms.

Storage

Recordings are uploaded to the configured File Store, same as File Upload fields. Length and quality settings depend on the user's browser/device.

Display a base image and let the user place markers, annotations, or shapes on it. Useful for fields like "Where on the diagram is the fault?" or "Mark the damage areas on this photo".

Conditional options

None at field level — the base image is supplied by the underlying data.

What gets stored

A JSON structure describing each plotted point or shape with its coordinates and label. The base image is referenced separately so the annotations can be rendered on top of it when the row is viewed.

Common uses

• Field service forms — "plot the damage on this car diagram".
• Construction / surveying — annotate site photos with measurements.
• Medical / dental — mark areas of concern on body or tooth diagrams.

Embed video from a hosting provider directly in a datastore row. The user enters a video ID or URL; the platform renders the embedded player on any page that displays the row.

Conditional options

• Provider (Required) — which service will host your videos? Pick from the supported list (YouTube, Vimeo, etc.).

What's stored

The video ID or URL as plain text. The embed is rendered at display time, so changes on the host provider (e.g. video deletion) are reflected immediately.

When to use this vs. File Upload

Use Web Video when videos are hosted externally — saves storage cost and offloads streaming. Use File Upload (with Files Allowed including video types) when the videos must live inside ActiveManage's file store.

A masked input — characters are hidden as the user types. Use for passwords, PINs, or any other sensitive string that shouldn't be visible on screen.

Conditional options

• Min Length — minimum acceptable length.
• Show Password Confirmation Box? — when on, the form renders a second masked input and requires both to match before submission. Use for change-password forms.

How the value is stored

By default, as plain text (so subsequent reads return the entered value). For genuinely sensitive secrets, also enable the field's Encrypt option to store the value encrypted at rest.

User passwords (.users table)

For actual user authentication, the platform manages password hashing internally — you don't use a Password field for that. Password fields are for application-data passwords (e.g. credentials a workflow stores for connecting to an external system).

An international phone-number input. The user picks a country (flag icon dropdown) and types the local number; the field formats the value automatically and stores it in E.164 international format.

Conditional options

None — the default behaviour covers most uses.

Validation

The input validates that the entered number matches the chosen country's format. Invalid numbers can't be submitted.

How the value is stored

As an E.164 string — e.g. +447700900123 for a UK mobile. This means joins, lookups, and SMS sending against the value all work without normalisation logic.

A PCI-compliant card-detail input. The user enters their card number, expiry, and CVC; the platform handles tokenisation through the configured payment provider (Stripe, by default) and stores only the safe token in the row.

Conditional options

None.

How card data is handled

• The card number is never sent to your server. The browser tokenises it directly with the payment provider's secure script.
• The token (and last 4 digits, brand, expiry) are returned to your server and stored on the row.
• Subsequent charges use the token, not the raw card number.

Configuration

Make sure Stripe is connected via Site Settings → Stripe (the public API key is what powers the front-end tokenisation). Without a connected payment provider this field type can't be used.

A multi-field input for postal addresses. The fields rendered (Address Line 1, Address Line 2, City, Region, Postal Code, etc.) adapt to the country picked at the top of the input.

Conditional options

• Enable Google Places Autocomplete (Required) — users can find addresses easily by using Google Places API to predict the address as the user types it. You must have a Google API key configured in ActiveManage to use this feature.

Country-aware layout

The platform stores country-specific field layouts under .countryaddressfields. Pick the country at the top of the field and the appropriate fields render — for example, the US shows State while the UK shows County.

How the value is stored

Each sub-field stored in its own column-like fragment under the field name. The full address can be reassembled for display via ##AMDATA_rowname## tokens that render the formatted multi-line address.

Capture geographic coordinates from the user's device. Useful for field-service apps, on-site logging, or any workflow where the row's location matters.

Conditional options

• Geolocation Scope (Required) — what kind of location data to collect. If you select the Postal Address option you will need to provide a valid Google Maps API key in Site Settings.
• Attempt to collect location automatically? — if this option is un-ticked the visitor will have to click a button to fetch their location.
• Show accuracy of location? — when on, the rendered field shows the GPS accuracy in metres alongside the coordinates.

Permissions

The browser will prompt the user for permission to share their location. Without permission, the field stays empty.

What's stored

Latitude, longitude, and (if enabled) accuracy. The platform can render the captured point on a map view using the same Google API key.

Generate a random alphanumeric string when a row is created. Use for invitation codes, single-use tokens, unique slugs, or anything else where you need a non-guessable identifier.

Conditional options

• Length of String (Required) — how many characters long. 12 is a sensible default for invitation codes; 32 or longer for opaque tokens.

How it's generated

At row creation, the platform generates a random string from the alphanumeric character set [a-zA-Z0-9]. The field is read-only on the form — users can't enter their own value (which would defeat the purpose).

Common uses

• One-time invitation codes for new users.
• Magic-link tokens for passwordless login.
• Short unique IDs for sharing URLs ("/share/AB12CDEF").

Type-ahead search against another datastore. The user starts typing, the platform queries the source table in the background, and matching results appear in a dropdown for selection.

Conditional options

• Data Source (Required) — which table the search runs against.
• Fields to Search (Required) — which columns the user's typed query is matched against.
• Unique Key Field (Required) — this will normally be ID (with no quotes). The value of this column is what the field stores.
• Minimum Characters (Required) — the minimum number of characters to perform AJAX request.
• AJAX Delay (milliseconds) (Required) — the length of time to wait for the user to finish typing before submitting the AJAX request. This delay is reset each time the text in the field is changed. Once the field is unedited for the amount of time specified, the AJAX request is submitted.
• Max Results (Required) — the number of results to show that match the criteria, all other results will be hidden.
• Output Format (Required) — how would you like the results displaying?
• Output String To Show — use %%FieldName%% (replacing FieldName with the actual field name) to use any field from the returned data. If blank, an array of all the data will be returned.
• Search Mode (Required) — controls match semantics (starts-with, contains, exact, etc.).
• Javascript Callback Function — invoked when a result is selected. Function signature: myCallbackFunction1(type, fieldname, ID, action).

Same as AJAX Search (DB) but the search target is an external HTTP endpoint rather than a local datastore. Use for integrating with third-party search APIs, internal microservices, or any other JSON-returning endpoint.

Conditional options

• Path to AJAX Script (Required) — the full URL of the external endpoint.
• Minimum Characters (Required) — minimum chars to start a search.
• AJAX Delay (milliseconds) (Required) — debounce delay before sending the request.
• Output Format (Required) — how would you like the results displaying?
• AJAX Variable Name (Required) — the request variable expected by the AJAX server. For example, if your AJAX script path is https://website.com/api/search/?q=test the variable name would be q.
• AJAX Results Property (Required) — the property in the JSON response that contains the results from the search.
• AJAX Results Unique Record Property (Required) — the property in the JSON answers response items that contains a unique value to identify the select value (e.g. id).
• Javascript Callback Function — invoked on selection.

Security

The endpoint is called from the user's browser. If it requires authentication, your endpoint must either be public, accept the user's session, or use a CORS-friendly token scheme.

Search Active Directory for users, groups, or computers. Useful for fields that need to reference a specific AD object — assignee fields, manager picker, asset assignments.

Conditional options

• Fields to Search (Required) — which LDAP attributes the user's query is matched against (e.g. displayName, mail, telephoneNumber).
• Show Photos? — when on, the dropdown displays the AD photo (thumbnailPhoto attribute) alongside each result.
• Include Disabled Accounts? — when off, disabled AD accounts are filtered out.
• Max Results (Required) — the number of results to show.
• Search Mode (Required) — using "string found anywhere in selected LDAP fields" is NOT recommended, as it causes significantly more time to process by the LDAP server. Stick to starts-with where possible.
• Output Format (Required) — how to display each result.
• Object Type (Required) — search for Users, Groups, Computers, etc.

Prerequisites

The platform must be configured with LDAP/AD credentials in ldaptoolkit.php — see your platform's AD integration setup.

A simpler AD picker than AJAX Search (Active Directory). Choose the object type at configuration time, then the field renders a picker for that one type.

Conditional options

• Object Mode (Required) — what type of Active Directory object will the user be able to search/select? Pick User, Group, or Computer.

What gets stored

The AD object's distinguished name (DN). The platform can resolve this back to display attributes (display name, email, etc.) at render time using ##AMDATA_* merge tokens.

Type-ahead picker scoped to ActiveManage users (the .users table). Use it where the row needs to reference an ActiveManage user — assignee, manager, account owner, etc.

Conditional options

None — the field uses sensible defaults (search by name and email, return matching users, exclude soft-deleted).

What's stored

The user's ID. Render at display time via ##AMDATA_rowname## to get the full name, email, or any other user attribute.

The Conditional Form field type renders a dropdown where each option, when selected, reveals its own set of sub-fields. It's how ActiveManage builds branching, dynamic forms — pick a Type and the type-specific fields appear; pick a different Type and a different set appears.

Conditional options

• Conditional Form (Required) — pick from your Conditional Forms (managed under Architect Panel → Conditional Forms). Each Conditional Form definition specifies the available options and the sub-fields each option reveals.

Where the platform uses Conditional Forms internally

Many of ActiveManage's own configuration pages are Conditional Forms — for example, the User Input View's Stage Timeout setting is a Conditional Form (Yes / No) where picking Yes reveals Time Period and Timeout Action sub-fields.

Creating a Conditional Form

See the Conditional Forms section. In short: name the form, list its options, and for each option list the fields that should appear when it's chosen.

Dynamic Conditional Form is like Conditional Form except both the options and the sub-fields are sourced from datastores. That way, admins can change which options appear (and which fields belong to each) without touching the field configuration.

Conditional options

• Table/Field Containing Options (Required) — the field that contains the names of the options you would like to show.
• Join Field Override — if no value is entered, the ID field will be used to join this table to the table containing the fields.
• Table/Field Containing Fields (Required) — the field that contains values linking the rows to the option table.

When to pick Dynamic over the standard Conditional Form

Pick Dynamic when:

• Options change frequently and a non-developer should edit them.
• The set of options is large enough that managing them as data is easier than managing them as configuration.
• Options need to vary per tenant or per environment.

Render a repeatable group of sub-fields with Add and Remove controls. The user can add as many instances as needed; each instance gets the full set of sub-fields configured for the group.

Conditional options

• Dynamic Add Field (Required) — pick from your Dynamic Add Fields definitions, managed under Architect Panel → Dynamic Add Fields.
• Javascript Callback Function — invoked when sub-rows are added or removed. Function signature: myCallbackFunction1(fieldname, ID, action).
• First Child ID — the number that will be used for the first ID of the dynamic add child. If no value is specified, the default value of 1 will be used.
• Store data in external table? (Required) — when on, each dynamic add entry is stored as a row in a separate table (one-to-many relational). When off, the entries are serialised into a single column on the main row (denormalised but simpler).
• Disable Multiple Entries — if you would just like to show multiple fields in a specific layout and don't need to allow multiple entries then you can toggle this option on.

Common uses

• Order lines on an order form (also see Line Item Builder).
• Multiple contacts on a customer record.
• Multiple attachments with per-file metadata.

The Line Item Builder is a purpose-built repeatable-row field for line items — invoice lines, order rows, quote items. It looks similar to Dynamic Add/Remove but with built-in conventions for product lookup, quantity, unit price, and totals.

Conditional options

• List Item Builder (Required) — pick a Line Item Builder definition from the Architect Panel → Line Item Builders admin.
• Store data in external table? (Required) — same trade-off as Dynamic Add: separate-table for relational integrity vs. serialised for simplicity.

Why pick Line Item Builder over Dynamic Add

• Built-in row total / overall total handling.
• Sensible default columns and validation for the line-item use case.
• Cleaner UI on the rendered form.

The SQL Query field type runs a SQL statement and displays the result. It's a display-only field — the user can't edit it; the value is computed every time the row is rendered.

Conditional options

• MySQL Query to Run (Required) — the SQL to execute. ##AMDATA_ID## will be replaced with the ID of the data row. Other field tokens (##AMDATA_fieldname##) are also substituted before execution.

What gets shown

The first column of the first row returned by the query. For multi-row or multi-column output, format your SQL accordingly — for example wrap in GROUP_CONCAT() to flatten multiple rows into one cell.

Use sparingly

Every render of a row that contains an SQL Query field runs an extra query. For browse views displaying many rows, this can be costly. Prefer regular columns + computed display formats where possible.

The Custom field type is the platform's escape hatch — render any HTML/JS you want inside the form. Use it when none of the 49 other field types fits, or when you need a custom widget tied to a JavaScript library.

Conditional options

• Custom Code (Required) — the HTML/JS to render in place of a standard input.
• Hide Field Label? — if this option is enabled, only the custom HTML code you enter will be shown as part of this field and the field label displaying the Friendly Name will be hidden.

Storing values

The Custom field doesn't have a built-in storage mechanism — you write JavaScript that pushes the user's chosen value into a hidden form input (or sets it via the AM form API) at submission time. The platform stores whatever ends up in that input.

When to use this

• Bespoke widgets like rating slidersrange filters that need a specific library.
• Complex visualisations the user interacts with to choose a value.
• Embedded third-party form components that need a hosting div + script.

The Custom PHP Code field runs a server-side PHP block and renders whatever the block returns. Display-only — like SQL Query, the user can't edit the value; it's computed on every render.

Conditional options

• Custom PHP Code (Required) — the PHP block to execute. Has access to the row's data and standard ActiveManage helpers ($AMDB, $AMuser, etc.).

How it works

The platform evaluates the PHP code with the row's data in scope. Whatever the code echos is rendered as the field value. Errors are caught and (in production) replaced with a generic error message.

Security considerations

Code entered here runs server-side with the full permissions of the web user. Restrict who can edit Custom PHP Code fields — usually only architect-level admins. The platform records every edit in the audit log.

Display a value pulled from the audit log for the row — for example, the email of the user who last updated the row, or the timestamp when it was created. The field is read-only and computed at render time.

Conditional options

• Audit Field to Show (Required) — pick from a list of audit fields. Common choices: "E-mail Address (Last Updated By)", "Date Created", "Date Last Updated", "Username (Created By)".

Prerequisites

The datastore must have audit mode enabled for the audit data to exist. Without audit mode on, Audit Link fields render blank.

Hidden fields exist on the row and accept a value but never appear on the user's form. They're useful for system-set values (created-by user ID, tenant ID, status flag set by a workflow) that the user shouldn't see or edit.

Hidden

Standard hidden field — has no type-specific options. The value is set programmatically (default value, callback function, or workflow action).

Special Hidden

A hidden field that's hidden in a more aggressive way — also omitted from the form's underlying DOM, so even via browser dev tools the field can't be manipulated by the user. Use for security-sensitive values that must never be tampered with from the client.

How to populate them

• Static default via the field's Default Value setting.
• Dynamic default via a Custom PHP Callback function on the parent form.
• Updated at workflow transitions (e.g. a UIV stage action setting the field to a new value).

The Dummy field is a placeholder used internally by the Conditional Forms system. Pick it when you need to reserve a position in a layout that the Conditional Forms engine will populate at render time.

Conditional options

• Conditional Form Master Row Name (Required) — the row name of the parent conditional form field that drives this dummy slot.
• Conditional Form Inner Row Name (Required) — the row name of the nested field this dummy stands in for.

When you actually need this

Almost never directly — the platform inserts Dummy fields under the hood when you build a Conditional Form. You'll likely only encounter this type when debugging an unusual conditional form layout.