Segregation of duties
This page explains why the person who creates a training version can never be the person who approves it, and why the rule holds even if you try to work around the screen.
Quality Admin, Corporate Admin, and quality owners who need to explain the control to an auditor.
The rule
The author of a pending version and the approver of that version must be two different people. An author cannot approve, activate, or reject their own work.
This is segregation of duties (SoD). It ensures that a second qualified person reviews content before it reaches learners, which is a core expectation under ISO 9001 and 21 CFR Part 11.
What you see in the UI
If you open the Quality Review Queue and find a version you authored, the Approve and Reject buttons on that card are disabled. The card shows a note:
You created this version - another Quality Admin must approve.
This is a guard, not the enforcement. It stops the obvious mistake before you make it.
How it is enforced
The disabled buttons are a convenience. The real check runs on the backend. When an approval or rejection request arrives, the server compares the caller against the version's author. If they match, it refuses the request with a 403 error and a sod_violation code. The version stays pending and nothing is activated.
So even if a request reached the backend some other way, an author still cannot approve their own version. The control does not depend on the browser.
The same server-side check also confirms:
- The caller holds a quality role (Quality Admin or Corporate Admin); otherwise the request is refused.
- The change rationale is at least 10 characters.
- At least one source is attached to the version.
What to do when you are blocked
If you authored a version that needs approval, ask another Quality Admin or a Corporate Admin to review it. They open the same task, compare the change, record their own rationale, and approve. Your name stays recorded as the author; theirs is recorded as the approver.
Why this is recorded
Both halves of the act are captured in the audit log. The author is on the version's creation event, and the approver is on the approve_content event with their rationale. An auditor can read both and confirm the two are different people.