Application forms
Build, version, and publish the questionnaires applicants complete in the Apply portal — using the question catalog, form templates, and the form builder.
An application form is the versioned questionnaire inside an application program. It defines which questions applicants answer, which cohorts they can apply to, submission deadlines, and optional integrations such as health insurance or study contracts. Every answer an applicant submits flows from a published form into the Applicants area, where staff review field answers before making admissions decisions.
Forms are the bridge between admissions configuration and live applicant data. A well-designed form captures the information your evaluators need, enforces required documents at submission time, and — through platform mapping — can sync accepted students into Fuxam user records without re-keying data.
Why it matters
Universities cannot run fair, auditable admissions on ad hoc PDFs and email attachments. Application forms give you a governed, structured intake: consistent questions across intakes, enforced deadlines, validated field types (email, phone, file upload), and version control so you can change next year’s questionnaire without breaking last year’s submissions.
Because forms are versioned, each publish creates a locked snapshot applicants see on the Apply portal, while administrators can draft changes for future intakes. That separation protects historical submissions — evaluators always review answers against the form version the applicant actually completed.
How this fits into Fuxam
Application forms sit in the middle of the admissions funnel: downstream from application programs and study programs and cohorts, upstream from applicant submissions and staff review.
Three building blocks feed form design, each with a different reuse model:
| Building block | Where it lives | What it provides | Reuse behavior |
|---|---|---|---|
| Question catalog | OrgHub → Management → Applications → Question catalog tab | Named sections of live questions (blocks) | Enabled per form; updates propagate when forms are saved or republished |
| Form templates | Settings → Application form templates | Initial field layout when creating a new form | One-time copy at form creation; not synchronized afterward |
| Custom fields | Form builder field palette | Program-specific questions added directly on a form | Unique to that form unless duplicated |
After you publish a program, applicants complete the form on the public portal. Their responses appear in the Pending tab of Applicants, where staff open the detail sheet to verify every field before recording a decision.
Key concepts
| Term | Meaning |
|---|---|
| Application form | The questionnaire inside a program — fields, catalog blocks, deadlines, cohort assignments, and optional integrations. |
| Form builder | The editor where you add custom fields, enable catalog blocks, configure required rules, conditional logic, and platform mapping. |
| Question catalog block | A reusable named section of questions maintained centrally and enabled on one or more forms. |
| Form template | An institution-wide starting layout stored in Settings — copied once when you create a new form. |
| Draft version | Unpublished changes in the form builder; not visible to applicants until you publish. |
| Published version | Locked snapshot applicants see on the Apply portal; prior submissions remain tied to the version they used. |
| Eligible cohorts | Intake cohorts applicants must choose from when applying — set at form creation. |
| Platform mapping | Links form field answers to Fuxam user profile fields so accepted applicants sync into institutional records. |
| Conditional logic | Rules that show or hide individual fields based on answers to other fields. |
Open application forms
Go to OrgHub → Management → Applications → Forms tab.
Select an application program name to open its Forms table.
The Forms tab lists all application programs. Drilling into a program shows its forms, versions, and publish state. From there you can create new forms, open the form builder, or manage submissions for a published form.
Roles and responsibilities
| Role | Typical form responsibilities |
|---|---|
| Admissions administrator | Create forms, maintain the question catalog, publish versions, set deadlines and cohort assignments. |
| Program coordinator | Define program-specific custom fields, review form content against accreditation requirements. |
| Admissions evaluator | Uses published forms indirectly — reviews the answers applicants submitted; does not usually edit form structure. |
| IT / org admin | Assign form-related permissions and maintain form templates for institution-wide consistency. |
Where to start
A typical form setup sequence:
- Confirm study programs and cohorts exist for the intakes you plan to open.
- Create an application program and link study programs.
- Optionally maintain shared content in the question catalog and form templates.
- Build an application form — add fields, enable catalog blocks, configure mapping.
- Preview your form to verify enabled catalog blocks.
- Publish the form, then publish the application program so applicants can access it on the portal.
If forms already exist and you are preparing a new intake, duplicate an existing form or start from a template, adjust cohorts and deadlines, preview, and publish a new version.
In this section
Build an application form
Add fields, enable question catalog blocks, configure mapping, and publish in the form builder.
Manage the question catalog
Maintain reusable question blocks shared and synchronized across forms.
Form templates
Create reusable field layouts in Settings for faster form setup.
Preview your form
Review enabled question blocks before publishing.