Department settings, templates, and group rules

Department setup in Academia is more than profile data. The platform already uses department-scoped settings to shape how projects start, how milestones are generated, and whether student groups are valid for proposal work.

Why this page matters

The current onboarding docs already mention settings, templates, phases, and policy defaults. Group formation docs also show that group size is enforced by real backend rules. This page brings those controls together as one department setup layer.

Fastest route through this guide

1. Read What the department controls to understand the setup surface.
2. Read Milestone templates and academic phases to see how project timelines are shaped.
3. Read Group rules and submission readiness to understand the student-side constraints created by department policy.
4. Continue to Onboarding and first setup if you want the wider rollout sequence.

What the department controls

The current frontend and backend indicate a real settings layer around:

• department identity and working context
• settings and configuration surfaces
• academic phase controls
• milestone templates and timing
• document templates and policy defaults
• group size and readiness rules

This matters because the department head is not only inviting users. The role is also shaping the rules the rest of the workflow will follow.

Milestone templates and academic phases

Milestone behavior in Academia is template-driven.

The current docs already confirm:

• the backend creates a default department milestone template during institution registration
• project creation can apply a milestone template automatically
• milestone due dates are computed from template durations
• many projects follow a sequential milestone model

The default department template already reflects a five-step flow such as:

1. Project Proposal
2. SRS
3. SDD
4. Implementation and Testing Report
5. Final Defense

This is the reason milestone setup belongs in department administration, not only in student or advisor workflow docs.

Why academic phases matter

Academic phase controls give the department a way to make the lifecycle legible.

In practice, these controls help the department decide:

• when proposal work should be active
• when milestone review windows should dominate the workflow
• when evaluation and defense preparation should become the late-stage focus

Document templates and policy defaults

The current setup flow already points to document templates and policy defaults as early department work.

That means the department can shape the expected submission structure before students begin uploading academic work.

Practical effects include:

• more consistent document expectations across projects
• fewer ad hoc reviewer instructions later in the lifecycle
• clearer handoff from proposal work into milestone and defense preparation

Group rules and submission readiness

Student group formation is not free-form. The group formation docs already show department policy influencing whether a group can become official.

The current behavior already confirms:

• minimum and maximum group size settings are enforced
• the group tracks current member count
• the group cannot be submitted until it reaches a valid state
• group approval is required before proposal work begins

This means department settings directly affect the earliest student workflow.

Why this matters to setup owners

If group-size policy is unclear or unrealistic, the proposal pipeline slows down before it really starts.

That is why department heads and coordinators should review these rules during setup instead of discovering problems only after students begin forming teams.

Practical setup order

The cleanest order for department configuration is:

1. confirm department identity and ownership details
2. review phase timing and workflow defaults
3. review or refine milestone templates
4. review document templates and policy expectations
5. confirm group-size rules and submission readiness constraints
6. invite staff only after the rules are clear enough to operate consistently

How these controls affect later workflow

Control area	Downstream effect
Milestone template	shapes project timeline, due dates, and sequential review behavior
Academic phases	helps departments align workflow timing and readiness focus
Document templates	keeps deliverables more consistent across students and reviewers
Group-size rules	determines whether teams can become valid and enter proposal work
Policy defaults	reduces ad hoc decisions during active project delivery

Common mistakes to avoid in the docs

• Do not describe settings as cosmetic administration only. They shape real academic behavior.
• Do not treat milestone templates as project-level accidents. They begin at the department level.
• Do not hide group-size enforcement inside student-only docs. It is a department rule.
• Do not document phases and templates separately from onboarding. They are part of first-run readiness.

Best page after this one

If you want to do next...	Go here	Why
Continue the setup sequence	Onboarding and first setup	It places these controls in the real rollout order.
See the role that owns these controls first	Department head	It explains the governance owner behind department configuration.
See how group rules affect students	Student group formation and approval	It shows where group-size and readiness rules become visible to users.

Best next reads

• Onboarding and first setup
• Department head
• Student group formation and approval