Approving, rejecting, querying

When reviewing a module, you have three actions. They have different consequences for the workflow and the trainer.

Approve

You agree the module is ready. Click Approve.

What happens:

• Module status flips from pending_approval to approved
• If this was the last step in the workflow, the course is fully approved (trainer can publish)
• If this was step N of a multi-step workflow, step N+1’s approvers get notified
• The trainer gets an email: “Module X approved by [you]”

You don’t have to wait for the whole course’s modules to be approved — you decide per module. As you approve, the course’s “modules approved” count ticks up. When every module in the course is approved, the trainer publishes.

When to use:

• The module’s flashcards are accurate and well-written
• The quiz questions are correct and well-designed
• The course settings are appropriate (pass threshold, recert, certificate)

When NOT to use:

• You’re not sure about something. Use Query instead.
• Major issues. Use Reject.

Reject

You disagree with something material — the module needs work before it can be published. Click Reject.

A modal opens asking for your feedback. Write specifics:

• “Question 3 has the wrong correct answer — should be B, not C.”
• “Card 7 contradicts our SOP — please update with the latest version.”
• “The course needs a recertification policy — please set 12-month recert before resubmitting.”

Click Send rejection.

What happens:

• Module status flips from pending_approval to draft
• The module’s ready_for_review_at is cleared (so the trainer has to re-mark it Ready)
• An approval_action row is recorded with action=reject + your comment
• The trainer gets an email with your comment
• The card appears in the trainer’s Queries tab

The trainer addresses the feedback, replies in the Queries thread, and clicks Send & Resubmit. The workflow then restarts from step 1.

When to use:

• Factual errors (wrong correct answer, contradicts SOP)
• Major omissions (missing content, missing settings)
• Major policy violations (wrong tag, wrong department, wrong pass threshold)

When NOT to use:

• Style preferences you can’t back up with policy. “I’d phrase this differently” is not a rejection — discuss in a query first.
• Minor wording issues. Use Query.

Ask a query

The middle ground. You have a question, comment, or hesitation but you’re not committing to a yes or no yet.

Click Ask query. A modal opens. Write your question or comment.

What happens:

• Module status STAYS at pending_approval (not rejected)
• An approval_reply row is recorded with your comment
• The trainer gets an email with your question
• The card appears in the trainer’s Queries tab

The trainer responds. You can read their response and then decide:

• Approve (their answer resolved your concern)
• Reject (their answer reinforces a problem)
• Ask another query (still working through it)

When to use:

• You’re not sure if the trainer’s choice was deliberate
• You spotted something that might be wrong but you’re not the SME
• You want clarification before committing to a decision

When NOT to use:

• You’re certain about a problem. Don’t dance around it; reject with clear feedback.
• You’re certain everything’s fine. Just approve.

The three-action mental model

Sure it's good        →  Approve
Sure it has problems  →  Reject
Not sure yet          →  Query

Most reviewers default to “Approve or Reject” because that feels decisive. Query feels like uncertainty, and reviewers worry it slows things down.

But Query is often the right answer. Approving when you’re unsure can let bad content through; rejecting when you’re unsure makes the trainer feel attacked. A query opens a conversation that often resolves faster than a reject-resubmit cycle.

Self-approval block

Reviewers can’t approve content they themselves authored — Wisteria blocks self-approval at every step. If you authored the course as a trainer and later became a content_manager, you’ll see the course in the queue but the Approve button is disabled with an inline hint.

In that case, escalate to another content_manager or to the super_admin.

Audit trail

Every approve, reject, and query is recorded with:

• Action type (module.approve, module.reject, approval.query)
• Actor (you)
• Resource (the module)
• Comment text (where applicable)
• Timestamp
• Workflow step number (so the audit shows “approved at step 2 of 3”)

Filterable from the audit log.

Notifications you send

The course-fully-approved notification fires only when every module is approved, not per-module.