Returning work to a student
Returning hands the submission back. Inline comments, summary comment, and rubric travel together. Two paths: finalize the grade, or ask for a revision. This doc covers both and what carries over on resubmit.
- When to return vs. just grade
- The two comment channels
- The rubric at return time
- The return action itself
- What the student sees
- The resubmit flow
- What happens to the recording
- When attempts are at the cap
- Signalling "revise" vs. "final"
- The notification stack on return
- Nudging a missing-submission student
- Returning a second time
When to return vs. just grade
Two end-states. Finalize: the rubric is the answer; score lands in the gradebook, passes back if LMS-bound. Return for revision: provisional; the student takes another swing, the next score replaces this one.
Return when something specific should change and attempts remain. Finalize when the submission is the work. maxAttempts: 1 can't be meaningfully returned.
Heuristic: comments about process ("missing thesis," "weak evidence in ¶3") suggest a return; comments about polish ("comma splice") suggest finalize. Work rushed in one 11 p.m. block often improves more with a return.
The two comment channels
Inline comments pin to a selection in the doc. The summary comment frames the whole piece.
Inline comments marks · notes
Highlight to comment. Proofreader marks (ins, del, cap, r-o) attach to a character range; longer notes attach to a paragraph.
Summary comment assignmentMessages
The per-student message thread, for holistic notes. Persistent across attempts. Own notification kind.
The novel's narrator spends three chapters describing the river before any action takes place. This pacing —
The rubric at return time setRubricScore
Pick one level per criterion. Save writes the rubric and flips status to graded.
Leave criteria unselected on a return — the student sees what you scored and what you skipped. Unscored criteria don't contribute to LMS passback.
The LMS score is normalized to 0–100: sum of chosen levels divided by sum of max, times 100. Skipped criteria count as zero on finalize, so a partial rubric posts low if finalized.
The return action itself
Two side-by-side actions in the grading sidebar. Save rubric finalizes. Return for revision opens a modal with one required field: the reason. OK flips status to returned-for-revision, stamps your reason, fans the notification.
Server-side on return:
statusflips toreturned-for-revision.- Reason lands on
submission.returnReasonwithreturnedAt+returnedByUserId. submission-returnednotification (icon↺) fans to the student. Bell badge increments, assignment card gets a red border, message thread carries the reason as banner.
Doesn't decrement attempts, lock the doc, change the recording, or post to LMS.
Auth: gradeSubmissions — same as saving a rubric, so TAs can return.
What the student sees
A red-accented banner at the top of the assignment info panel: your reason, return timestamp, Acknowledge & continue button.
Status pill changes from Submitted to Returned. Stays Returned after acknowledgement — only resubmit flips it back, and that's when the attempt counter ticks up.
Submit button relabels to Resubmit; attempts-remaining text updates. Acknowledge is one click confirming they've read it; the banner stops blocking.
The resubmit flow
Resubmit edits the same doc — no fork, no branch. Marks, comments, recording stay on one canvas; resubmit is a state change, not a content event.
The student edits, clicks Resubmit. That fires submissions.setStatus('submitted'), bumps attemptCount, records a new submittedAt. Partial rubric scoring stays.
Inline comments don't auto-clear. They stay anchored to their text — you see which suggestions the student addressed. Deleted underlying text detaches the mark gracefully ("stale" render).
What happens to the recording
The provenance recording continues across the return. Resubmit is a continuation — same timeline, more keystrokes, the whole revision visible end-to-end.
The scrubber stretches, with markers at the original submit and the resubmit. Scrub to "writing after my return" and watch only that portion.
A student who reworks writes hundreds of new characters between return and resubmit. A copy-paste of a friend's revision shows a tall spike with no surrounding session. The recording tells those apart.
When attempts are at the cap maxAttempts
Cap of 1 + a submission = zero attempts left. Return leaves Resubmit disabled and the banner inert — finalize is your only path.
Two enforcement points. The submit check rejects resubmit when attemptCount >= maxAttempts. Return still works at the cap — you can leave a written return even when no cycle can run.
To re-enable, bump maxAttempts from the edit modal. That bumps the assignment version and fans an assignment-update notification.
setStatus sidesteps the attempts check — for testing or recovery (browser crash, student emails you the doc). Sparingly.
maxAttempts to re-enable the cycle.
Signalling "revise" vs. "final"
The return action tells the student why they're seeing the rubric. Finalized reads "this is the score." Returned reads "this is what I'm seeing so far — try again." The status pill and banner make it loud.
If your class is new to revision, spell it out in the summary: "I've returned this — fix the thesis and the evidence in para 3, then resubmit. Other scores stand." Makes the partial rubric legible and the return directive.
The opposite signal also helps. Finalize with "Solid work; not asking for a revision on this one" when a class defaults to many attempts.
The notification stack on return submission-returned
The student gets a bell-flyout entry and a red-badged count on the assignment card.
Payload:
kind: 'submission-returned'— distinct fromsubmission-graded, grouped with the↺glyph.title— assignment title prefixed "Returned: …".body— the first ~120 characters of your reason.refKind: 'submission',refId— click lands on the info panel with the banner expanded.
Students mute kinds in Settings → Notifications. Muting submission-returned drops bell and email and suppresses the Nudge surface.
Nudging a missing-submission student submissions.nudgeStudent
Non-submitter rows carry a Nudge button. One click sends an in-app notification plus email. Reads as a reminder, not a reprimand.
What the student sees
Bell row with kind: 'nudge', assignment title, one-line body ("Your teacher is waiting on this one"). Email mirrors with a deep link.
24-hour dedupe
A second Nudge within 24h is a no-op. Server checks reminderLog for audience 'nudge' on { assignmentId, studentUserId }. Toast confirms.
Mute-aware
Muted nudge: no bell row, no email. Button still records; dedupe still applies.
Custom-message variant
The caret next to Nudge opens a one-line field to replace the default body. Logs on reminderLog.
reminderLog audience 'nudge'.Mute: if the student has muted
nudge, in-app and email both suppress; the log row still records the attempt.
Returning a second time
You can return as many times as maxAttempts allows. Each cycle: banner, edit, resubmit, counter advances.
Recording stretches; thread keeps every message; inline marks accumulate. A three-time-returned student has a richly annotated doc and a full revision recording.
Returning the same work repeatedly without changing the ask is a signal your rubric isn't doing its job. If your attempt-2 comments echo attempt-1, the criterion needs a clearer level description.
Related
- Creating an assignment — where
maxAttempts, rubric, and self-assessment prompts get set. - Co-teachers & TAs — who can return (TAs can;
gradeSubmissionsis in the TA tier). - Setting up your first class — classroom defaults for
defaultMaxAttemptsanddefaultRubric. - Back to the help library.
Something missing or wrong? Email feedback.