Prepare and submit an admission application

Use this workflow to turn an inquiry into a numbered formal application, record the applicant's identity claims, and submit the application for review. It ends with Submitted status and the review checklist supplied by the intake. Student enrollment and offer acceptance are later workflows.

This guide describes the reviewed Odoo 20 Community source. It has not been exercised as a complete browser journey. See Education: getting started for the compatibility qualification and its limits.

Before you begin

The Admissions addon depends on Students, which brings Academics, Documents, and Core with it. Use an ordinary signed-in Admission Officer account with the intended campus assigned and its company enabled. Admission User is a reading role. Admission Manager includes the officer role but does not automatically include decision, override, protected-document, or conversion authority.

Have these records ready:

• An Open intake for the applicant's campus. Today's date must fall between its Application Open Date and Application Close Date when you create the formal application. The Admission Manager maintains the intake under Admissions → Configuration → Admission Intakes, including its academic year, program, grade, curriculum, target class, capacity, and review definitions.
• A governing Application sequence policy for that campus and date. The Education Administrator maintains these under Education → Configuration → Sequence Policies. Use a policy approved and activated for your operation; application numbering is generated by the system.
• The applicant's name and the identifier facts your organization is authorized to record. Each identifier claim needs a type, issuer, and value. Submission requires at least one claim.

The system uses the intake and policy governing the application. It does not ask you to type an application number or choose a different campus after conversion.

Create the formal application

1. Open Admissions → Operations → Inquiries and create an inquiry. Enter Applicant Name, Campus, and Intake. Select an intake belonging to that same campus. Add Email, Phone, and Notes as appropriate, then save.
2. Confirm the inquiry is New and review its applicant and scope details. Choose Create Formal Application.
3. Check the application that opens. It should be Draft, with a generated number, the governing intake and sequence policy, and the applicant's name, email, and phone copied from the inquiry. The inquiry is now Converted and linked to this application. One inquiry can create only one formal application.

Expected result: a numbered draft application that can be found again under Admissions → Operations → Applications. The Applications form disables direct creation; the inquiry action is the starting point.

Prepare the identity facts

4. Review Applicant Name, Email, Phone, and Date of Birth on the draft application. Correct them before submission.
5. In Identifier Claims, add at least one row with Identifier Type, Issuer, and Value. Issuer and value must contain letters or numbers. The system normalizes these values when comparing identifiers, so changing punctuation or letter case does not make an otherwise identical claim distinct. New claims show Unverified; submission does not mean the claim has been verified.
6. If applicable, complete Application Parties, Temporary Household, and Delegates with the authorized facts for this application. These are application facts; do not assume that recording a party or a delegate has already created a student enrollment or granted portal access.
7. Save and check all identity details, claims, parties, household facts, delegates, and the intake. Numbered applications cannot be deleted, and submission makes these facts immutable. Resolve mistakes before continuing.

Submit and check the result

8. Choose Submit. The system attempts to resolve the identifier claims to a single person. It may reuse a matching person within the permitted identity scope or create a person when there is no match. Conflicting identities or matches outside the permitted campus scope can block submission; have the responsible admissions or student-records administrator investigate the supplied facts.
9. Confirm Submitted status, Canonical Person, Submitted By, and Submitted On. Check Immutable Events for the submission event.
10. Open Review Checklist and Evaluations. Submission creates rows from the intake's active checklist and evaluation definitions. Review work follows submission; a submitted application is not evidence that these requirements have already passed. Where there are no active evaluation definitions, the evaluation list can be empty.

Expected result: a submitted application whose identity and intake facts are fixed, with an attributable submission event and the applicable review work visible.

Where this guide stops

The supplied form displays Review Checklist, Eligibility Assessments, Evaluations, Exception History, Decision History, Offers and Seats, and Conversion history as read-only lists. This guide does not provide a click sequence for recording decisions, issuing offers, or accepting them because those controls are not supplied by this form.

A Convert to Student button is visible to users with Admission Conversion Authority on submitted applications. It has additional checks and separate Student authority requirements; Submitted alone does not establish readiness for conversion. Continue only through a separately validated conversion workflow.

Common stopping points

What you see	What to check
No Create Formal Application button	The account needs Admission Officer, and the inquiry must still be New.
“The inquiry is not eligible for this open intake revision.”	Check intake status, today's date against its application window, matching campus/intake, and whether the inquiry already has an application.
“No active application sequence policy governs this campus.”	Ask the Education Administrator to check the Application policy's scope and effective dates.
“Add at least one identifier claim before submission.”	Add a genuine claim in the draft with its type, issuer, and value.
Identity cannot be resolved, or claims conflict	Ask the responsible administrator to reconcile the identity facts. Do not create altered identifiers merely to bypass the message.
Submitted details are read-only	The application has crossed its immutable submission boundary. This guide supplies no reset-to-draft procedure.

Return to Education: getting started for the shared structure and access setup.