Skip to main content

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.

Who this is for

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.

Screenshot pendinga review task card the current user authored, with Approve and Reject disabled and the segregation-of-duties note

This is a guard, not the enforcement. It stops the obvious mistake before you make it.

How it is enforced

The server enforces SoD, not the screen

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.