# 3. Rejection & Flagging

User Type: **Super Administrator**
Source: *Mi Digital Academy - Education CRM Features Document*

---

## 3. Rejection & Flagging

### 3.1 Reject Content with Reasons
**What it does:** Rejects content that does not meet the review criteria, with the reasons: the Super Administrator (or the reviewer) rejects a content item and records the specific reasons for the rejection, so the creator knows why it was rejected and what to fix. Rejection is a definitive outcome (the content is not approved), distinct from a flag (which is a marker for further action).

**Sub-features:**
- Content rejection: the content rejected (not approved)
- Rejection reasons: the specific reasons recorded (the issues)
- Reason specificity: the reasons are specific (the issue, not a vague "rejected")
- Creator notification: the creator informed of the rejection and the reasons
- Resubmission: the creator can fix and resubmit (the rejection is not a dead end)
- Rejection record: the rejection recorded (the reviewer, the reasons, the time)
- Audit logging of the rejections

**Super Administrator User Journey:**
1. A content item in review does not meet the criteria (a quality/accuracy/standards issue). Super Admin (or the reviewer) rejects it.
2. Records the specific reasons: the issues (the wrong answer, the unclear section, the misalignment), so the rejection is actionable, not opaque.
3. The rejection is recorded: the reviewer, the reasons, and the time, so it is auditable.
4. The creator is notified of the rejection and the reasons; they know what to fix.
5. The creator fixes the issues and resubmits the content; it re-enters the review queue (the rejection is not a dead end).
6. For a resubmission, the reviewer re-reviews (the fix verified); the content is approved if the issues are resolved.
7. Reviews the rejection pattern: the recurring rejection reasons (a common issue type), so the content owners are informed (the root cause addressed).
8. The rejections are audit-logged with the content, the reviewer, the reasons, and the timestamp.

**Rules & Edge Cases:**
- A rejection is a definitive outcome (the content is not approved); it is distinct from a flag (a marker for further action).
- The reasons are specific (the issue, not a vague "rejected"); the rejection is actionable.
- The creator is notified of the rejection and the reasons; they are not left guessing.
- A resubmission is allowed (the fix and the re-review); the rejection is not a dead end.
- The rejection is recorded (the reviewer, the reasons, the time); it is auditable.
- Rejections are audit-logged with the content, reviewer, reasons, and timestamp.

### 3.2 Flag Inappropriate or Incorrect Content
**What it does:** Flags content that is inappropriate or incorrect: the Super Administrator (or the reviewer, or a learner's report) marks the content with a flag, so it is identified for further action (a review, a takedown, a correction) without necessarily being rejected outright. A flag is a marker — it signals an issue that needs attention, and it can be applied to content that is already live.

**Sub-features:**
- Content flagging: the content marked with a flag (the issue identified)
- Flag types: the flag categories (inappropriate, incorrect, outdated, other)
- Flag on live content: a flag applied to content that is already live
- Flag action: the action the flag triggers (a review, a takedown, a correction)
- Flag resolution: the flag resolved (the issue addressed, the flag cleared)
- Flag record: the flag recorded (the flagger, the type, the time)
- Audit logging of the flags

**Super Administrator User Journey:**
1. A content item is found to be inappropriate or incorrect (by the reviewer, or by a learner's report). Super Admin (or the reviewer) flags it.
2. Sets the flag type: the category (inappropriate, incorrect, outdated, other), so the flag is specific.
3. The flag is recorded: the flagger, the type, and the time, so it is auditable.
4. For a flag on live content, the flag triggers the action (a review, a takedown, a correction) per the flag type; the content is handled.
5. For an incorrect-content flag, the content is corrected (the error fixed) and the flag is cleared (the issue resolved).
6. For an inappropriate-content flag, the content is taken down (removed from the learners' view) and the flag is cleared (the issue resolved).
7. Reviews the flag queue: the open flags (the unresolved issues), so the flagged content is worked down (not left flagged).
8. The flags are audit-logged with the content, the flagger, the type, and the timestamp.

**Rules & Edge Cases:**
- A flag is a marker (the issue identified); it is distinct from a rejection (a definitive outcome).
- A flag can be applied to live content (it is not only for pending content); a live issue is caught.
- The flag type is specific (the category); the action is per the type (the review, the takedown, the correction).
- A flag is resolved (the issue addressed, the flag cleared); it is not left open indefinitely.
- The flag is recorded (the flagger, the type, the time); it is auditable.
- Flags are audit-logged with the content, flagger, type, and timestamp.

### 3.3 Provide Feedback to Content Creators
**What it does:** Provides feedback to the content creators on their content: the Super Administrator (or the reviewer) gives the creator the feedback on their content (the issues, the suggestions, the what-to-fix), so the creator can improve their work. Feedback is the communication channel that turns a rejection or a flag into a learning moment for the creator, improving the future submissions.

**Sub-features:**
- Creator feedback: the feedback given to the creator on their content
- Feedback content: the issues, the suggestions, and the what-to-fix
- Feedback delivery: the feedback delivered to the creator (the notification, the message)
- Feedback specificity: the feedback is specific (the issue, the fix, not a vague note)
- Feedback history: the feedback per creator (the pattern over time)
- Creator improvement: the creator's work improving over the feedback
- Audit logging of the feedback

**Super Administrator User Journey:**
1. For a rejected or flagged content item, Super Admin (or the reviewer) provides the feedback to the creator: the issues, the suggestions, and the what-to-fix.
2. Makes the feedback specific: the issue (the wrong answer, the unclear section), the fix (how to correct it), and the suggestion (how to improve it), so it is actionable.
3. Delivers the feedback to the creator (the notification, the message); the creator receives it with the content's context.
4. The creator reviews the feedback and improves their work (the fix made, the suggestion applied); the next submission is better.
5. Reviews the feedback history per creator: the pattern over time (the recurring issues, the improvement), so the creator's development is visible.
6. For a creator with a recurring issue (a common error type), Super Admin provides targeted feedback (the specific guidance) so the root cause is addressed.
7. Confirms the creator improvement: the creator's work improving over the feedback (the rejection rate falling, the quality rising); the feedback is working.
8. The feedback is audit-logged with the content, the creator, the feedback, and the timestamp.

**Rules & Edge Cases:**
- The feedback is given to the creator on their content; it is the communication channel for the rejection/flag.
- The feedback is specific (the issue, the fix, the suggestion); it is actionable, not a vague note.
- The feedback is delivered to the creator (the notification, the message); they receive it with the context.
- The feedback history is per creator (the pattern over time); the creator's development is visible.
- A recurring issue gets targeted feedback (the specific guidance); the root cause is addressed.
- Feedback is audit-logged with the content, creator, feedback, and timestamp.