Forms

Almost every form you'll build in ActiveManage starts from a datastore — the platform auto-generates an HTML form by introspecting the datastore's fields. From there you can layer in conditional logic, custom validation, custom field types, and reusable rules to get exactly the experience you need.

The forms engine is one of the platform's most heavily-used features because every place a user inputs data ultimately renders as a form. Get comfortable with the engine and you'll be building rich, validated, branching forms without ever writing HTML.

What the forms engine gives you

Out of the box, every datastore comes with:

• Auto-generated New/Edit forms for every datastore, with no per-form template work needed.
• 50+ field types covering text, numbers, dates, files, signatures, geolocation, AJAX search, repeatable groups, and more.
• Conditional Forms — show/hide entire field groups based on a parent field's value.
• Custom Form Rules — fine-grained show/hide/required logic between any pair of fields.
• Dynamic Add Fields — repeatable sub-forms for one-to-many data (line items, multiple contacts, etc.).
• Custom validation rules attached to fields.
• User Input Views — multi-stage forms with approval workflows on top of the auto-generated form.
• API exposure — every form's underlying datastore is reachable via the API with the same validation applied.

Where forms live in the admin panel

Most form configuration is on the datastore itself — fields are added there. Beyond that, several form-specific admin areas exist under the Architect Panel → Forms category:

• Conditional Forms — reusable conditional field-group definitions.
• Custom Forms — bespoke form layouts when the auto-generated one isn't right.
• Dynamic Add Fields — repeatable sub-form definitions.
• Line Item Builders — specialised repeatable rows for invoice or order line items.
• User Input Views — multi-stage approval forms (with its own section in these docs).

How a form is composed

An ActiveManage form is made up of three kinds of building block:

1. Standard datastore fields

The bulk of every form — one input per field on the underlying datastore. The field's Field Type determines exactly what's rendered. See the Datastore Field Types section for a dedicated article on each.

2. Conditional fragments

Conditional Form fields render a dropdown where each option reveals its own sub-fields. Use them whenever the relevant set of inputs depends on a top-level pick ("Is Auto-Renew on?" → reveals an Auto-Renew Date when Yes).

3. Repeatable groups

Dynamic Add Fields and Line Item Builders render groups that the user can repeat — one for each address, contact, line item, etc. The platform handles adding, removing, and reordering rows.

Three real-world form layouts

Example 1: Simple contact capture

One datastore (contacts) with fields for name, email, phone, message. The auto-generated form is exactly right — no conditional logic, no repeatable sections, just five fields rendered in order. Done in 10 minutes.

Example 2: Multi-step purchase request

One datastore (purchase requests). A Conditional Form field at the top picks the request type (Office Supplies / IT Hardware / Software License) and each option reveals a different set of follow-on fields. A Line Item Builder at the bottom lets the requester add multiple items with quantity and unit price. Total cost auto-computed.

Example 3: Multi-stage approval workflow

One datastore (leave applications). The form is rendered as a User Input View — the requester fills in the basics at stage 1, the line manager reviews and approves at stage 2, HR records the leave at stage 3. Different fields are visible at each stage; different actions are available; different emails fire at each transition.

Tip: Start with the simplest form that works. The auto-generated form for a datastore is often good enough on its own — add Conditional Forms only when you genuinely need branching, add Dynamic Add Fields only when you need repeatable sub-groups. Resist the temptation to over-design; you can always add complexity later.

An ActiveManage form is assembled from three kinds of building block that compose together. Understanding the three categories and how they relate makes form design predictable rather than guesswork.

The three building blocks

1. Standard datastore fields

The bulk of every form — one input per field on the underlying datastore. The field's Field Type determines exactly what's rendered. The platform ships over 50 field types covering essentially every kind of input:

• Text inputs (Text Box, Text Area, WYSIWYG Editor, Code Editor, Password).
• Numbers (Number, Slider).
• Dates and times (Date, Date and Time, Time).
• Selection (Tickbox single/multiple, Toggle Switch, Radios, Dropdown variants, Pills).
• Files and media (File Upload, File Store Selection, Signature, Screen Recorder, Web Video, Image Plotter).
• Location and contact (Postal Address, Phone Number, Geolocation, Credit/Debit Card).
• Lookups (AJAX Search variants, User Search, Active Directory Object).
• Display and computation (SQL Query, Custom HTML, Custom PHP, Audit Link, Icon, Random Alphanumeric).

See the Datastore Field Types section for a dedicated article on each type.

2. Conditional fragments

Conditional Form fields render a dropdown where each option reveals its own set of sub-fields. Use them whenever the relevant set of inputs depends on a top-level pick.

Three concrete examples:

• A Status dropdown with options "Open / Closed / Declined" reveals a Reason text area only when Declined is picked.
• An Auto-Renew toggle reveals an Auto-Renew Date field when On.
• A Request Type dropdown reveals entirely different question sets per type (an IT request asks about device and operating system; a facilities request asks about location and severity).

3. Repeatable groups

Dynamic Add Fields and Line Item Builders render groups that the user can repeat. The platform handles adding, removing, and reordering rows; the data is stored either inline (denormalised) or in a child table (relational).

Three concrete examples:

• A Contacts repeatable group on a Customer form lets the user add one or more contacts, each with name/role/email/phone.
• A Line Items repeatable group on an Invoice form lets the user add product / quantity / unit price rows, with automatic line-total and invoice-total computation.
• An Attachments repeatable group on a Support Ticket form lets the user upload multiple files, each with a description of what it shows.

How they compose

The three categories aren't separate — they compose freely. A form can have standard fields at the top, a Conditional Form field in the middle that reveals different sub-fields per option, and a Line Item Builder at the bottom. Within a Conditional Form option's revealed sub-fields, you can have a Dynamic Add Field. And so on, to whatever depth makes sense.

Custom widgets when nothing fits

If none of the standard types covers your case, the platform has escape hatches:

• The Custom field type lets you render bespoke HTML/JS inside the form. The hardest part is wiring up your custom widget to save its value into the row's storage; the rest is just HTML.
• The Custom PHP Code field type renders server-computed HTML at render time. Display-only — the field doesn't accept input from the user, it just shows computed content.

Both are powerful but rarely needed. Most forms can be built entirely from the standard set.

The auto-generated form layout

By default, fields appear in the order you've configured them on the datastore. Each field's Edit View Width determines its horizontal proportion — fields with similar widths line up side-by-side; wider fields push to their own row.

For finer-grained layout control (multi-column layouts that don't follow width-based stacking, deliberately grouped sections with headings, etc.), use a Custom Form. The Custom Form replaces the auto-generated layout with a hand-authored HTML template that references your datastore fields by row name.

Every field on every form runs through validation before the underlying row is saved. ActiveManage validates client-side (for instant feedback as the user types) and again server-side (to catch anything the client-side validation might have missed or that a malicious user might have bypassed). Without validation, your datastores fill up with bad data and the consequences ripple out to every downstream use.

Built-in rules

The platform ships with sensible rules for common patterns:

• Email format — rejects strings that aren't valid email addresses.
• URL — rejects strings that aren't valid URLs.
• Postcode — rejects invalid UK postcodes; other country formats configurable.
• Regex match — rejects strings that don't match a custom pattern.
• Numeric range — rejects numbers outside a min/max bound.
• Length range — rejects strings shorter than a min or longer than a max.
• Date range — rejects dates outside a from/to bound.
• File size — rejects file uploads above a maximum byte size.
• File MIME type — rejects file uploads whose MIME type isn't in a list.
• Required — rejects empty submissions.
• Unique — rejects values that already exist on another row in the same column.

Each field has a Validation setting where you pick which rule (or rules) apply. Validation runs in addition to type-level constraints (a Number field implicitly validates that the input is a number; a Date field implicitly validates that it's a parseable date).

Custom rules

For business-specific validation (e.g. "VAT number must match the customer's country"), add a custom rule to the Validations admin. Each rule is a PHP callback that receives the value (and optionally the rest of the row's data) and returns true to accept or a string error message to reject.

Examples of custom rules that come up:

Example 1: Domain restriction on email

For a B2B app where only corporate emails are accepted: a custom rule that rejects gmail.com, hotmail.com, yahoo.com etc. Implementation: PHP callback checks the email's domain against a blacklist.

Example 2: Business-day-only dates

For a date field that should only accept Mon-Fri: a custom rule that takes the date and rejects if it falls on a Saturday or Sunday.

Example 3: Cross-field consistency

"End date must be after start date" — a rule that fires on the end-date field, looks at the start-date field on the same row, and rejects if end is before start.

Required fields

The Required flag on a field is its own validation rule. It only fires when the field is visible — conditionally-hidden fields can be Required without triggering on submission while they're hidden. That's the correct behaviour because users can't fill in fields they can't see.

Where validation errors appear

Inline, immediately next to the field with the error. The error message comes from the validation rule itself ("Please enter a valid email address" or "This field is required"). The user can't submit the form until every error clears — the submit button stays disabled or returns to the form with errors shown.

Server-side enforcement

Crucially, validation runs server-side too. If a client-side check is bypassed (a curl call directly to the API, a malicious user disabling JavaScript), the same rules fire at save time. If anything fails server-side the row isn't saved and the user gets an error message.

This is why custom validation should always be implementable in PHP — client-side-only validation isn't safe. The platform's built-in rules all have server-side equivalents.

Note: Validation rules attached to a field apply across every place the field is used — the auto-generated form, Custom Forms, User Input Views, the API. There's one source of truth (the field's Validation setting); everything else respects it.

The action that runs after a successful form submission depends on which type of form was submitted. The options span a thank-you message, a URL redirect, a callback function, or a full multi-stage workflow — each suited to different use cases.

Standard datastore forms (New / Edit)

By default, after saving a row via the standard New or Edit form, the form closes and the user returns to the datastore listing (or whichever page they were on). If the row was edited, the new values show in the list immediately.

For most internal admin tasks, that's exactly the right behaviour — finish, return to context. No configuration needed.

User Input Views

UIVs have a dedicated Success Action field with three options:

1. Show a thank-you message

Renders custom HTML on the same page after submission. Best for keeping the user on-site with a clear acknowledgement of what they just did.

2. Redirect to a URL

Sends the browser to any URL you specify. Useful when the success state has its own dedicated page (a confirmation page with more detail, a portal home page, an external survey).

3. Run a custom function

Invokes a PHP function defined in customfunctions.php and shows whatever HTML the function returns. Use this when the success state needs to be computed at runtime — different message depending on what was submitted, conditional next steps, dynamic content.

See the dedicated Submission Success Actions article in the User Input Views section for the full detail.

Custom Forms

Custom Forms allow you to wire up arbitrary submit handlers. The form's Submit Target setting is one of:

• Insert into a datastore — same as standard datastore forms.
• Update a specific row — for self-service forms that edit the user's own profile or similar.
• Custom URL — POSTs the form data to a URL of your choice. Your handler decides what to do with the data.
• Custom PHP function — calls a named PHP function with the form data.

Triggering workflows on submission

Beyond the immediate post-submit behaviour, you can configure things that happen because a row was saved. These run after every successful save (insert or update):

1. Post-insert / post-update hooks

PHP functions defined on the datastore's configuration. The platform calls them after every insert or update with the saved row's data. Useful for cascading changes — "when a new order is created, also create the corresponding invoice draft".

2. Trigger Tasks

The Task Engine can have triggers configured per datastore. Trigger types: "on insert", "on update", "on delete", "on column-X change". Useful for scheduling delayed actions or for actions that should happen out-of-process.

3. UIV stage progression

For rows in a UIV-backed datastore, the row's stage transitions automatically based on the workflow rules. The submission itself is just stage 1; stages 2+ kick off afterwards.

Three real-world submission flows

Example 1: Internal time-off request

UIV with Success Action = "Show thank-you message". Message: "Your leave request ##REFNUMBER## has been submitted. Your manager will review within 2 working days." Workflow continues at stage 2 for manager review.

Example 2: Customer contact form

Custom Form with Submit Target = "Insert into contacts datastore". Post-insert hook fires that sends an internal notification email to the support team. Form rendered on a public Page Builder page; success action redirects to a thank-you page.

Example 3: B2B order submission

Standard datastore form for placing orders. On submit, a trigger Task creates the corresponding invoice draft, reserves stock, and queues a fulfilment notification — all out-of-process so the user gets immediate feedback while the platform handles the side-effects asynchronously.