Build an application form

Create and configure an application form with question types, catalog blocks, sections, platform mapping, and publish workflow in the form builder.

Use the form builder inside an application program to design the questionnaire applicants complete on the Apply portal. The form builder is where admissions configuration becomes concrete: every field you add, every catalog block you enable, and every mapping you set determines what applicants see at submission time and what evaluators review in the applicant detail sheet.

A form is not a static document — it is a versioned, publishable artifact tied to specific cohorts and deadlines. Understanding the builder’s two content areas (catalog blocks and custom fields) and how they feed review is essential to designing forms that work for both applicants and staff.

Why it matters

Admissions forms must balance competing needs: applicants need a clear, completable experience; evaluators need structured, verifiable data; and your institution needs consistency across intakes and programs. The form builder addresses all three by offering validated field types, reusable catalog sections, required-field enforcement, conditional logic for complex questionnaires, and platform mapping so accepted students do not re-enter data already collected at application time.

Poor form design creates downstream cost: missing required documents force Needs update cycles, unmapped fields mean manual data entry at enrollment, and publishing changes mid-intake can disrupt active applicants. Investing time in the builder before go-live reduces review friction and protects data quality through to user management.

How it fits

Forms live inside programs — you reach the builder by opening a program’s Forms table from OrgHub → Management → Applications → Forms. Content can come from three sources: a form template at creation time, question catalog blocks enabled in the builder, and custom fields added from the field palette. After publishing, answers flow to staff review; mapped fields can sync into user records when applicants are enrolled.

Key concepts

How to create a form

How to add fields and sections

The form builder has two main areas:

• Question catalog blocks — reusable sections from the question catalog. Enable blocks, set their order, and mark blocks as required.
• Custom fields — individual questions you add from the field palette.

Forms typically combine both: catalog blocks for institution-wide sections (personal details, documents, declarations) and custom fields for program-specific questions evaluators need during review.

Question types

When adding custom fields, choose from these types:

Choose the type that matches how you will evaluate the answer. File upload fields are essential for transcripts and identity documents — evaluators expand uploads in the detail sheet during review. Validated types (email, phone) reduce data quality issues before answers reach staff.

Required and optional

For each field or catalog block:

• Toggle Required so applicants must answer before submitting.
• Leave optional fields blankable — useful for supplementary information.

Catalog blocks can be marked Required at the block level in form preferences, requiring all questions in that section.

Conditional logic

Individual fields support conditional logic — show or hide a field based on answers to other fields. Configure rules in the field properties panel.

Conditional logic helps keep forms manageable: ask follow-up questions only when a prior answer triggers them (for example, work experience details only when the applicant selects “employed”). Note that the preview dialog does not simulate conditional logic interactions in real time — verify rules in the builder layout.

Platform mapping

Map field answers to Fuxam user profile fields (core user data, custom fields, statistics fields, or insurance fields) so accepted applicants sync cleanly into your institution’s records.

Platform mapping is most valuable for fields applicants will never re-enter after enrollment — legal name, date of birth, contact details, insurance identifiers. Plan mapping before publish so enrollment workflows do not require manual transcription from the submission detail sheet.

How to save and publish

Saving preserves work in progress; publishing creates the locked version applicants see. After publishing, ensure the parent application program is published so the form is reachable on the Apply portal.

Best practices

• Design for reviewers — Structure sections in the order evaluators prefer to read (identity, documents, program fit, supplementary). Answers appear in the detail sheet in form order.
• Use the catalog for shared content — Institution-wide sections belong in the question catalog so updates propagate across forms when saved or republished.
• Use templates for starting layouts — Form templates speed up new form creation; customize cohorts and deadlines per intake afterward.
• Map early — Configure platform mapping while building, not after submissions arrive.
• Preview catalog blocks — Use Preview your form to verify enabled blocks before publishing.
• Version deliberately — Treat publish as a commitment for active intakes; draft changes for the next cycle rather than editing live versions mid-stream.

Common pitfalls

• Confusing catalog blocks with templates — Catalog blocks stay synchronized across forms; templates are a one-time copy at creation. See Form templates for the distinction.
• Wrong cohort assignments — Applicants only see cohorts listed under Eligible cohorts. Mismatched cohorts cause confusion at submission and review.
• Publishing without program publish — A published form inside an unpublished program may not be visible on the portal. Coordinate form and program publish.
• Editing a live form carelessly — Confirm version prompts; active applicants may be on the current published version.
• Skipping preview — Custom fields outside catalog blocks are not shown in the catalog preview dialog; review those directly in the builder.

FAQ

Related pages