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.