Red Stet
← Back to Help
Help · For teachers · Tier 2 — Day-to-day teaching

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. Covered here: both paths, and what carries over on resubmit.

In this doc
  1. When to return vs. just grade
  2. The two comment channels
  3. The rubric at return time
  4. The return action itself
  5. What the student sees
  6. The resubmit flow
  7. What happens to the recording
  8. When attempts are at the cap
  9. Signalling "revise" vs. "final"
  10. The notification stack on return
  11. Nudging a missing-submission student
  12. 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.

Use both, but not for the same thing. If your summary reads "see inline notes," skip it. The summary is for what you'd say about the piece as a whole.

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.

Return doesn't trigger LMS passback. Save grade posts to Canvas / Schoology; Return for revision writes the status flip + banner only. Partial rubrics survive a return — the next pass picks up where you left off.

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:

  1. status flips to returned-for-revision.
  2. Reason lands on submission.returnReason with returnedAt + returnedByUserId.
  3. submission-returned notification (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, and the recording stay on one canvas.

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 ("stale" render).

An update gates resubmit. If you edited the prompt, rubric, or due date between submissions, the student must acknowledge before Resubmit lights up.

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.

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.

Teachers bypass the cap. Teacher-side setStatus sidesteps the attempts check — for testing or recovery (browser crash, student emails you the doc). Sparingly.

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." That makes the partial rubric legible and the return unambiguous.

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 from submission-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.

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.

Returning the same work repeatedly without changing the ask usually means the rubric is too vague. If your attempt-2 comments echo attempt-1, the criterion needs a clearer level description.

Finalize at any point. A twice-returned student can be finalized on attempt 3 even with attempts left. The cap is a ceiling, not a quota.

Related

Something missing or wrong? Email feedback.