Skip to main content

Staff oversight and assignment

This page goes one level deeper into the staff orchestration layer of Academia. It explains how coordinators and department heads move from passive visibility into active control over advisor coverage, evaluator assignment, project readiness, and department-wide monitoring.

:::tip Use this page when You need the coordinator or department-head control layer for assignment coverage, late-stage bottlenecks, and project readiness monitoring. :::

Fastest route through this guide​

  • Start with End-to-end sequence if you want the short staff workflow.
  • Jump to Step 4 if you care most about evaluator assignment rules.
  • Jump to Staff-side state model if you are documenting intervention states rather than user-facing workflow steps.

Why this phase matters​

The platform does not end with student submissions and evaluator scoring. Department staff still need an operational layer that answers questions such as:

  • which projects still have no advisor or no evaluators
  • which advisors are overloaded or underused
  • which evaluators still have pending work
  • which late-stage projects are stalling before defense
  • which assignments need intervention now

Roles in this phase​

RoleResponsibility in staff oversight
CoordinatorMain operational owner for assignment, evaluator progress, reminders, and project tracking
Department headGovernance owner for department-wide assignment health, readiness, and escalations
AdvisorAppears as a supervised resource with workload, project, and milestone progress data
EvaluatorAppears as an assigned reviewer whose completion rate and pending queue can be monitored

Best page after this one​

If you want to continue into...Open this page
the late-stage evaluator and defense flow this oversight layer managesEvaluation and defense workflow
the milestone and advisor-review work that feeds staff trackingMilestone delivery and advisor review
the role-oriented explanation of coordinator and department-head responsibilitiesRoles and dashboards

End-to-end sequence​

The current staff workflow is best understood as seven steps:

  1. Staff reviews department-wide assignment summary.
  2. Staff opens a project and checks advisor and evaluator coverage.
  3. Staff assigns or reassigns the advisor when needed.
  4. Staff assigns evaluators and removes invalid assignments.
  5. Staff reviews advisor overview analytics for capacity and progress.
  6. Staff monitors evaluator completion and sends reminders.
  7. Staff uses project tracking and reports to escalate bottlenecks.

Step 1: Review assignment coverage across the department​

Staff first needs a high-level answer to whether the department is operationally covered.

Main backend endpoint​

  • GET /projects/assignment-summary

Access rules​

  • allowed roles: DEPARTMENT_HEAD, COORDINATOR

What this summary is for​

This endpoint exists to answer assignment coverage questions across the department before a staff user opens any one project in detail.

Practical use​

Use this view to see whether projects are missing:

  • advisor coverage
  • evaluator coverage
  • balanced late-stage staffing

Step 2: Open project-level assignment controls​

After identifying a project that needs attention, staff moves into the project assignment surface.

Strongest frontend evidence​

The coordinator projects page already includes a real assignment dialog with:

  • current advisor information
  • currently assigned evaluators
  • eligible evaluator loading
  • remove evaluator action
  • live assignment refresh after updates

What this tells us​

Even though some coordinator navigation routes are still placeholders, project assignment is already one of the strongest real staff flows in the frontend.

Placeholder visual​

Coordinator assignment placeholder

Step 3: Assign or reassign the advisor​

Advisor coverage is the first required staff decision after a proposal becomes a real project.

Main backend endpoints​

  • GET /projects/advisors?departmentId=<departmentId>
  • PUT /projects/:projectId/advisor

Important ID rule​

When assigning the advisor:

  • path :projectId is the real project id
  • request body must send advisor userId
  • do not send the advisor profile id as advisorId

Why this matters​

This is one of the most important ID distinctions in the whole product. Staff screens often show both the advisor profile id and the advisor user id, but assignment endpoints require the user id.

Step 4: Assign evaluators to late-stage projects​

Evaluator assignment is the handoff from supervision into formal review.

Main backend endpoints​

  • GET /projects/:id/evaluators
  • GET /projects/:id/evaluators/eligible
  • PUT /projects/:id/evaluators
  • DELETE /projects/:id/evaluators/:evaluatorUserId

Access rules​

  • evaluator assignment is owned by DEPARTMENT_HEAD and COORDINATOR

Important assignment rules​

  • at least one evaluator id is required when assigning
  • assigned advisor cannot also be evaluator on the same project
  • evaluator users must belong to the same department as the project
  • eligible lookup excludes already assigned evaluator users and the advisor user id

Current frontend behavior​

The coordinator assignment dialog already supports:

  • loading eligible evaluators
  • showing assigned evaluator cards
  • adding selected evaluators
  • removing existing evaluator assignments
  • showing live evaluator count on project cards

Step 5: Inspect project staff detail and readiness​

Staff does not only assign people. It also needs one project-level readiness view with assignment signals.

Main backend endpoint​

  • GET /projects/:id/staff-detail

What this endpoint includes​

  • project detail
  • evaluator list
  • department unassigned counts
  • assignment status flags such as whether the project already has an advisor or evaluator coverage

Why this matters​

This is the clearest backend signal that the product supports a dedicated staff readiness view, not just a list of projects.

Step 6: Use advisor overview analytics for workload and progress​

Staff decisions get better when they are backed by department-wide analytics instead of single-project guesswork.

Main analytics endpoints​

  • GET /analytics/advisors/overview
  • GET /analytics/advisors/:advisorId
  • GET /projects/advisors/:id/workload

What the advisor overview provides​

The advisor overview response is designed to show:

  • department-level summary totals
  • advisor profile and capacity information
  • assigned projects under each advisor
  • progress indicators for those projects
  • group and member context under supervised work

Important ID rule again​

  • advisorProfileId is used for advisor-profile analytics routes
  • advisorId is the real user id
  • when another endpoint expects a user id, use advisorId, not advisorProfileId

Practical use​

Staff can use this layer to:

  • balance advisor load
  • inspect which advisors have too many active projects
  • inspect project progress without opening every project individually

Step 7: Track evaluator progress and send reminders​

Once evaluators are assigned, staff still needs operational follow-through.

Strongest frontend evidence​

The coordinator dashboard and dedicated evaluator-progress screens already expose:

  • assigned project count per evaluator
  • pending evaluation count
  • submitted and reviewed counts
  • completion percentage
  • last activity snapshots
  • reminder and feedback actions

Supporting coordinator screens​

  • coordinator dashboard evaluator progress card
  • evaluator progress page
  • notify evaluators page
  • evaluation setup page for rubric and phase organization

Practical use​

This is the layer where staff keeps evaluators moving when defenses are close and score submission deadlines are approaching.

Step 8: Monitor project tracking across the department​

Assignment quality and evaluator progress still need to connect back to the real projects.

Main analytics endpoint​

  • GET /analytics/projects/tracking

What this tracking endpoint is designed for​

  • paginated department project tracking
  • group details
  • milestone progress
  • milestone statuses
  • approved submission file visibility

Why this matters​

This gives coordinators and department heads a single place to see whether operational assignment work is actually translating into project movement.

Step 9: Recognize the current frontend maturity level​

Not every staff route is equally mature yet.

What is already strong​

  • coordinator dashboard overview
  • coordinator project assignment flow
  • evaluator progress and reminder pages
  • evaluation setup screens

What is still partial or placeholder-based​

  • several coordinator role section routes still map to placeholder pages in the role router
  • this means the docs should distinguish between proven specialized pages and generic coordinator navigation placeholders

Documentation rule​

Describe the real operational model confidently, but avoid claiming that every coordinator navigation item is fully integrated already.

Staff-side state model​

The staff experience can be thought of in four practical states.

State A: Unassigned or incomplete coverage​

  • project is missing advisor or evaluator coverage
  • main actions: assign advisor, assign evaluators

State B: Assigned but not yet progressing cleanly​

  • advisor and evaluators exist
  • project still shows bottlenecks in milestones, reviews, or pending evaluations
  • main actions: inspect advisor overview, inspect project tracking, send reminders

State C: Active late-stage monitoring​

  • evaluation work is underway
  • evaluator progress and defense readiness need close observation
  • main actions: track evaluator completion, review project tracking, monitor readiness

State D: Completed oversight cycle​

  • assignments are in place
  • evaluations are submitted or reviewed
  • staff shifts from intervention to reporting and final oversight

Coordinator versus department-head view​

The two staff roles overlap, but they are not identical.

Coordinator​

  • owns operational movement
  • executes advisor and evaluator assignment
  • sends reminders and tracks progress actively
  • works closest to project-level bottlenecks

Department head​

  • owns governance and final oversight
  • reviews escalations and assignment health across the department
  • uses summary and tracking signals to intervene at the policy or management level

Best next reads​