The rejection-and-resubmit cycle

When you reject a module, you’re not ending the conversation — you’re starting one. This page walks through the cycle from your side as the reviewer.

After you reject

The module’s status flips from pending_approval to draft.
The trainer gets an email with your comment.
The module disappears from the Pending Approval column on the kanban.
The module appears in the trainer’s Queries tab at /admin/approvals/queries.

Your work on this module pauses until the trainer responds.

When the trainer responds

The trainer addresses your feedback (edits the module) and replies in the Queries thread. They click Send & Resubmit.

What that does:

A new approval_request is created for the module.
The module flips back to pending_approval.
The workflow restarts at step 1. Even if you were at step 2 or step 3, the chain runs fresh.
You (and any other step-1 approvers) get notified.

The module reappears in the Pending Approval column with a fresh card.

Reviewing the second pass

When you open the module again, you’ll see:

The current version of the module (with the trainer’s edits)
A history strip showing the previous rejection comment + the trainer’s reply

Things to check on a re-review:

Did the trainer actually address your concern? Sometimes they reply with reasoning rather than changes — be explicit in your next response about whether reasoning is enough.
Did the fix introduce new issues? Edits often cascade. If they fixed question 3, did they break a card that referenced question 3’s wrong answer?
Anything you missed the first time? A re-review is a chance to catch things you didn’t notice initially.

Three patterns

Pattern 1: Clean fix, approve

Most common. Trainer addressed the feedback, version 2 is good. Approve.

Pattern 2: Partial fix, re-reject or query

The fix addresses some of the feedback but not all. Two options:

Re-reject with a clearer specification of what’s still wrong. The cycle continues.
Query if you’re not sure whether the remaining issue is a problem — the trainer may have a reason you didn’t anticipate.

Pattern 3: Fix introduced a new problem

The trainer fixed your original concern but broke something else. Reject again with a comment that covers both:

“Q3’s correct answer is right now — thanks. But card 7 still references the old wrong answer; please update.”

Why the workflow restarts at step 1

A reasonable question if you’re step 2 or step 3: “Why am I being notified again? Step 1 already approved this — they should re-review first.”

The reason: a fix at step 1 might affect what step 2 or 3 needs to see. If the trainer addresses a step-2 rejection in a way that changes the module’s structure, step 1 has new content to evaluate. Restarting ensures every reviewer reads the final version.

It’s slower than resuming mid-chain, but it’s safer. The auditable record shows every reviewer signed off on the actual final version.

How long can a rejection cycle go

Indefinitely. There’s no limit on the number of reject-fix-resubmit rounds.

In practice, rounds 1 and 2 cover 95% of cycles. If you’re on round 5+, something’s wrong:

Misaligned expectations between you and the trainer — schedule a synchronous chat to align
The content is genuinely contentious — escalate to a third reviewer or to super_admin
The trainer is over-trying-to-please — reassure them; sometimes “good enough” is good enough

The escalation path

If a cycle is stuck, escalate by:

Replying in the Queries thread inviting the super_admin to weigh in (mention them by name)
Asking the super_admin to override-approve (they can; it’s logged as a super_admin override)
Going synchronous (call, Slack DM) and summarising the resolution in the thread for audit

When NOT to reject

A reject creates work for everyone — you, the trainer, and re-notified reviewers. Don’t reject for:

Style preferences without policy backing. “I’d phrase this differently” is not enough. Discuss in a query first.
Issues you could fix yourself. If you spot a typo and you have edit access (super_admin), fix it directly rather than rejecting.
Issues that don’t block the module from being correct. Save those for a separate improvement task.

When ABSOLUTELY to reject

Factual errors that would teach learners the wrong thing
Compliance violations (wrong pass threshold for regulated content, missing tags, missing recert)
Bullying or inappropriate content
Anything that would embarrass the workspace if it shipped

Every other case is closer to “discuss” than “reject.”

Audit trail

Every cycle iteration is recorded:

module.reject (your action)
approval.query_reply (any non-resubmission replies)
module.resubmit_after_rejection (the trainer’s resubmit)

For compliance customers, this thread is the auditable record of how every course iterated to approval.