Skip to main content

Student group formation and approval

This page goes one level deeper into the earliest student workflow in Academia. It explains how students move from individual accounts into an officially approved project group before proposal submission begins.

Fastest route through this guide​

  • Start with End-to-end sequence if you want the shortest summary of the student group workflow.
  • Jump to Step 2 if you care most about how students become group leaders or join existing groups.
  • Jump to Student-side state model if you are documenting what students see in draft, submitted, approved, or rejected group states.

Why this phase matters​

The student story in Academia starts before proposal upload.

This phase decides:

  • who can become an approved group leader
  • how students create or join a project group
  • how the team reaches the right size and composition
  • when the group becomes officially approved for proposal work
  • whether the proposal phase can start at all

Roles in this phase​

RoleResponsibility in group formation
Student group leader applicantApplies to become the student who can create and manage a group
Approved student group leaderCreates the group, invites students, manages membership, and submits the group for review
Student memberJoins a group through requests or invitations and waits for official approval
CoordinatorReviews submitted groups and approves or rejects official registration
Department headOversees the policy and readiness context behind group formation

Best page after this one​

If you want to continue into...Open this page
the student proposal flow after group approvalProposal review and approval
the full end-to-end lifecycleProject lifecycle
the student role view across the whole journeyStudent

End-to-end sequence​

The current early student workflow is best understood as eight steps:

  1. Student enters the department and opens the team area.
  2. Student either applies to become a group leader or browses groups to join.
  3. Approved group leader creates a draft group.
  4. Group leader invites students and handles join requests.
  5. Group reaches valid size and readiness.
  6. Group leader submits the group for department review.
  7. Coordinator approves or rejects the submitted group.
  8. Approved group leader can move into proposal submission.

Step 1: Student enters the project-group layer​

The student experience does not begin at proposal upload.

What the frontend shows​

The team area is already a real student workspace for early project coordination. Depending on the student's status, the UI exposes tabs such as:

  • My Group
  • Browse Groups
  • My Requests
  • Become Manager

Why this matters​

This tells us the platform treats project groups as the first operational student unit, not as an afterthought added later.

Step 2: Student becomes a group leader or joins an existing group​

This is the first major branch in the student journey.

Path A: Apply to become a group leader​

The backend supports a dedicated group-leader request flow:

  • POST /group-leader-requests
  • GET /group-leader-requests/me

The frontend already supports:

  • entering a reason for becoming a group leader
  • seeing pending, approved, or rejected request state
  • reviewing rejection feedback if the application is rejected

Path B: Browse groups and request to join​

Students who are not becoming leaders can browse available groups and request membership.

The backend supports:

  • GET /project-groups/browse
  • POST /project-groups/:groupId/join-requests
  • GET /project-groups/me/join-requests
  • POST /project-groups/me/join-requests/:requestId/cancel

The frontend already supports:

  • searching groups by name or manager
  • viewing group details
  • sending a join request with a message
  • tracking request status over time

Step 3: Approved group leader creates the draft group​

Only approved group leaders can create and manage a draft group.

Main backend rule​

The backend explicitly enforces approved group-leader status before group creation or management actions are allowed.

What the group leader can do​

  • create a draft group
  • set group details such as name, objectives, and technologies
  • open the group management surface in the team page

Why this matters​

Group creation is not open to every student account. The docs need to reflect that the group leader is a platform-approved role.

Step 4: Build the group through invitations and join requests​

The group does not become official as soon as it exists.

Invitation path​

The group leader can invite students directly while the group is still in DRAFT.

Join-request path​

Students can request to join a draft group, and the group leader can:

  • approve the request
  • reject the request with a reason
  • monitor pending requests in the group management flow

Current rules that matter​

  • groups can become full
  • non-joinable groups reject join requests
  • only approved group leaders can manage group membership actions
  • join and invitation activity is tied to the department context

Step 5: Reach a valid group state​

The frontend and backend both treat group size as a real rule, not just a recommendation.

Current behavior​

  • the group tracks current member count
  • minimum and maximum group size settings are enforced
  • the group cannot be submitted until it is valid for review

Why this matters​

Students need to understand that official registration depends on group quality and completeness, not only on pressing submit.

Step 6: Submit the group for department review​

Once the draft group is complete, the approved group leader submits it for formal review.

Main backend endpoint​

  • POST /project-groups/me/submit

Current product direction​

The frontend already describes this as the step where the group moves from editable student coordination into official department review.

Step 7: Coordinator approves or rejects the submitted group​

Submitted groups are not final until department review happens.

What happens here​

  • coordinator reviews the submitted group
  • group is either approved or rejected
  • if rejected, the group leader can reopen and revise the group
  • if approved, the group becomes officially registered for proposal work

Important backend behavior​

The current backend supports reopening a rejected group back to draft, which means rejection is part of a guided correction loop rather than a dead end.

Step 8: Approved group moves into proposal submission​

This is the handoff from group formation into the proposal phase.

What changes after approval​

  • the group is now the official student project unit
  • the approved group leader can move into the proposal workflow
  • the early student journey gives way to the proposal deep dive and later milestone work

For the next phase, see Proposal review and approval.

Student-side state model​

The student group experience is easiest to understand through five working states.

State A: No group yet​

  • student has not joined any group
  • main actions: apply to become a group leader, browse groups, request to join

State B: Draft group in progress​

  • group exists but is still editable
  • main actions: invite students, approve join requests, refine details, reach valid size

State C: Submitted for review​

  • group is waiting for coordinator review
  • membership editing should be treated as constrained until a decision is made
  • main action: wait for official review outcome

State D: Rejected and reopened​

  • group needs correction before official registration
  • main actions: reopen, fix issues, resubmit

State E: Approved group​

  • group is officially registered
  • main action: move into proposal creation and submission

Group-leader versus group-member view​

The platform does not give every student the same early workflow.

Group leader​

  • applies for approval first
  • creates and manages the draft group
  • invites members and decides join requests
  • submits the group for official review

Group member​

  • browses existing groups or responds to invitations
  • tracks join-request status
  • waits for the group to become officially approved
  • joins the proposal and project journey after group approval

Documentation rule​

Do not describe the student journey as if every student creates a proposal alone.

The real platform expects a project-group workflow first, and proposal activity starts only after that structure is in place.

Best next reads​