The admissions funnel
How an application moves through Fuxam Apply — the five stages from configuration to enrollment, the application statuses, and the common transitions.
The admissions funnel is the path every application takes in Fuxam Apply — from configuration and the public Apply portal through staff review and decision to Enrolled. Staff work the funnel in Campus Management → Applications (visible only when Application Management is enabled for your institution).
Why it matters
Admissions is not a single click but a governed funnel: intake windows, structured questionnaires, multi-stage review, conditional offers, contracts, and finally placement into a cohort. Apply keeps configuration, applicant data, decisions, and notifications in one system instead of scattered spreadsheets and email threads. Status updates tell applicants where they stand, trigger review emails at the right moments, and show colleagues which files need attention.
Before you start
| Requirement | Detail |
|---|---|
| Application Management | Enabled for your institution. See Apply portal settings. |
| Permissions | Permission to view application programs and forms, or to view individual applicant submissions on user profiles, depending on the task. |
| Study programs and cohorts | Must exist for the intakes you plan to open. See Study programs and cohorts. |
The five stages
A typical journey through Apply looks like this:
Configure — Enable Application Management, set portal branding, create application programs linked to study programs, build and publish application forms, and share the Apply portal URL from apply portal settings.
Apply — Applicants browse programs on the public portal, select an intake cohort, complete the form (with optional draft save), and submit. They receive a confirmation email and can track submissions under My Submissions.
Review — Staff open the Applicants area, filter the Pending tab, review field answers, request changes if needed, and communicate outside automated emails when appropriate.
Decide — Evaluators approve or reject, set statuses such as Conditionally accepted, and move applicants through stages toward Accepted or Rejected.
Enroll — After conditions are met (study contract, documents, etc.), status moves to Enrolled, which may trigger user provisioning and cohort assignment — the handoff from admissions to user management and study programs and cohorts.
Not every submission visits every state. Your institution may skip stages, use Conditionally accepted before Accepted, or rely on the Pending requirements area (when visible) to track outstanding items.
Application statuses
Typical progression (your institution may skip or reorder stages):
| Status | Meaning |
|---|---|
| Draft | Applicant started but has not submitted |
| Pending | Awaiting initial processing |
| Submitted | Application received, not yet under review |
| In review | Admissions team is evaluating the submission |
| Needs update | Applicant must correct or supplement answers |
| Conditionally accepted | Accepted pending conditions (documents, contract, etc.) |
| Accepted | Offer extended |
| Enrolled | Applicant enrolled into the cohort / institution |
| Rejected | Application declined |
| Withdrawn | Applicant withdrew |
Common transitions
| From | Common next stages | Notes |
|---|---|---|
| Draft / Pending | Submitted (applicant action) | Staff rarely set these except for data correction. |
| Submitted | In review | Signals evaluation has started. |
| In review | Needs update, Accepted, Rejected, Conditionally accepted | Decision or correction branch. |
| Needs update | Submitted (after resubmit) | Applicant edits eligible fields. |
| Conditionally accepted | Accepted, Enrolled | Conditions met → advance. |
| Accepted | Enrolled | May prompt contract/cohort dialogs. |
| Any active stage | Withdrawn | Applicant-initiated or recorded by staff per policy. |
Step-by-step instructions for changing a status are in Move to next stage; to change several applicants at once, see Bulk process applications.
Common pitfalls
| Pitfall | What happens | What to do |
|---|---|---|
| Enrolled set before onboarding is done | Enrolled may trigger account creation and cohort assignment | Verify the study contract first (see the warning in Approve or reject) |
| Stale Submitted files | High-volume intakes pile up without triage | Bulk-move to In review to show active processing |
| Expecting an email for every status | Review emails are not sent for Draft or Pending | Use manual communication where the applicant needs to hear from you |
| Bulk-updating enrolled applicants | Submissions in Enrolled are skipped by bulk changes | Process them individually |
FAQ
Can we define custom stage names?
The pipeline uses fixed application status values. Your process maps to these statuses; you cannot add arbitrary stage names beyond the supported set.
Where do accepted applicants appear in the table?
Accepted and enrolled submissions appear on the Accepted tab of the Applicants list, as well as in status filters on Pending when still mid-pipeline.
What happens at Enrolled?
Status Enrolled indicates the applicant is placed into the cohort or institution. This may trigger user account provisioning, study contract completion, and system code assignment depending on configuration.