Custom Forms

When ActiveManage's auto-generated form for a datastore isn't the layout you want, Custom Forms let you build a bespoke form from scratch. Pick which fields to show, how to lay them out, what styling to apply, and where to submit them — without changing the underlying datastore.

When to use a Custom Form

Most forms in the platform are auto-generated and that's the right default. Reach for a Custom Form when:

• You want a multi-column layout the auto-generator can't produce. Two- or three-column forms with deliberate field grouping, side-by-side related fields, or specific visual hierarchy.
• You need a form embedded inside a Page Builder page with custom branding. The auto-generated form has its own styling; a Custom Form can match the surrounding page exactly.
• The submission target is somewhere other than the originating datastore. Forms that POST to an external API, that call a custom PHP function, or that compose multiple operations on submit.
• You want a public-facing form without exposing the admin form's auto-generated UI. Public-facing forms often need different styling, simpler validation, or restricted field sets compared to the internal admin form.
• You need conditional layout (not just conditional fields). Showing/hiding entire sections of the form, restructuring the layout based on user choices, etc.

When NOT to use a Custom Form

For internal admin forms, the auto-generated form is usually right. Building a Custom Form is significant work — you're hand-authoring HTML where the auto-generator did the work for you. Don't reach for Custom Forms just to tweak the field order; you can do that on the datastore itself.

How they're managed

From the Architect Panel → Forms → Custom Forms. Each Custom Form has:

• Name — internal name.
• Target — datastore + action (insert/update), or custom URL, or custom PHP function.
• Layout — HTML template with placeholders for fields.
• Field list — which datastore fields the form uses.
• Submit behaviour — what happens after success.
• Visibility rules — who can see/submit this form.

Three real-world Custom Forms

Example 1: Public contact form on a marketing page

Target: contacts datastore (insert). Layout: two-column with name + email on the first row, then a full-width message field, then a submit button. Branded styling matching the surrounding page. Auto-redirect to a thank-you page on submit.

Example 2: Customer profile self-edit

Target: users datastore (update current user's row). Layout: tabbed sections (Profile / Preferences / Notifications / Security). Restricted field set — users can edit their preferences and name but not their email or role. Submit message: "Your profile has been updated."

Example 3: Multi-step product configuration

Target: products datastore (insert). Layout: a step-by-step wizard with progress indicator. Different fields visible per step. Save and continue between steps; final submit creates the product row.

Tip: Before building a Custom Form, try the alternatives. If you just need different field order, reorder fields on the datastore. If you need conditional reveals, use Conditional Forms. If you need a stylistic tweak, see if it can be done via CSS on the auto-generated form. Custom Forms are powerful but the maintenance burden is real — every datastore change needs to be propagated to the Custom Form by hand.

Building a Custom Form involves three main steps: configuring the form's metadata (name, target, behaviour), composing the HTML layout, and testing the end-to-end submission flow.

1. Name and target

From the Architect Panel → Forms → Custom Forms, click New.

• Name — internal name. Pick something descriptive ("Public Contact Form", "Customer Profile Self-Edit", "New Product Wizard").
• Target Type — pick what the form does on submit:
  • Insert into datastore — creates a new row.
  • Update specific row — edits an existing row (the row ID is passed via URL or context).
  • Custom URL — POSTs the form data to a URL of your choice.
  • Custom PHP function — calls a named PHP function with the form data.
• Target Datastore / URL / Function — the specific destination.
• Visibility — which security groups can see and submit this form.

2. Compose the layout

The layout is HTML with placeholders for each field. Use ##FIELD_rowname## to insert the input for a specific datastore field. Wrap inputs in your own divs, columns, and headings for full control of the visual structure.

Example layout snippet for a contact form:

<div class="row">
  <div class="col-md-6">
    <label>Your Name</label>
    ##FIELD_name##
  </div>
  <div class="col-md-6">
    <label>Email</label>
    ##FIELD_email##
  </div>
</div>
<div class="row mt-3">
  <div class="col-12">
    <label>Your Message</label>
    ##FIELD_message##
  </div>
</div>
<button type="submit" class="btn btn-primary mt-3">Send Message</button>

The platform replaces each ##FIELD_*## placeholder with the appropriate input HTML for that field type — text input for Text Box fields, select for Dropdown fields, etc. Validation rules attached to the underlying datastore fields still apply.

3. Field list

List every datastore field your form uses. Fields not in this list aren't included in the submission, even if you reference them in the layout. This is the gatekeeper against accidentally exposing fields you didn't mean to.

4. Validation

Validation rules attached to the underlying datastore's fields still apply automatically — Custom Forms don't bypass them. If you need additional client-side rules specific to this form, add JavaScript in the layout that hooks into the form's submit event.

5. Embedding

Custom Forms can be embedded in:

• Page Builder pages via a form block — pick the Custom Form from a dropdown.
• Friendly URLs — configure a Friendly URL that targets the Custom Form directly.
• Any HTML — Custom Forms can also be included via their URL inside an iframe, or rendered by code that calls the platform's form-rendering helper.

6. Test before going live

End-to-end test:

1. Open the Custom Form via its embedded location.
2. Fill in valid values; verify it submits successfully.
3. Try invalid values; verify validation messages appear correctly.
4. Check the resulting row appears in the target datastore with the right values.
5. Verify any post-submit behaviour (redirect, thank-you message, notification email).

Tip: Keep your Custom Form's field list in sync with the underlying datastore. If you add a field to the datastore and want it on the Custom Form, you need to add it to the field list and reference it in the layout — the auto-generation that happens for standard forms doesn't apply here.