CAPA

CAPA stands for Corrective & Preventive Action. When something fails — a temperature breach, a critical checklist item, a short delivery — a CAPA incident captures it, routes it to an owner, and holds it open until someone has found the root cause, fixed it, and proven the fix worked. It is the loop an inspector looks for, and the reason a recurring failure stops recurring.

Where CAPAs come from

Most CAPAs are not created by hand — they open themselves the moment another pillar detects a problem:

• A critical checklist item fails → a CAPA opens with the failed item and any photo evidence attached.
• A quality / HACCP breach (out-of-range temperature, failed CCP) → a CAPA opens, and a work order too if equipment is implicated.
• A receiving discrepancy (quantity does not match) → a CAPA opens, deep-linked from the receiving screen with item-level evidence.
• A recurring equipment failure (the same asset fails repeatedly) → a CAPA auto-escalates so the pattern is investigated, not just patched again.
• A customer complaint → logged through complaint intake as a CAPA.
• By hand — click + New (/capa/new) for anything you spot that should be tracked.

The inbox

CAPA opens on a three-tab inbox that collapses the full state machine into the buckets a manager actually thinks in:

• Open — anything not yet ready to verify (newly opened, under investigation, action pending).
• Awaiting — the action is done and it is waiting for sign-off.
• Closed — verified and closed in the last 30 days.

Filter by search, severity, or source; narrow to just mine or overdue; and sort by priority (the default) or date. An Unassigned > 24h chip surfaces incidents that opened automatically and have been sitting without an owner past the service window — the ones most likely to fall through. Export register downloads the queue for an HQ or regulator review.

Working a CAPA — the loop

1. 1

   Triage

   Open the incident and assign an owner and a due date. Severity is pre-set from the source and can auto-escalate if the same problem keeps recurring.
2. 2

   Investigate

   Record the root cause, attach evidence (photos, readings), and link related records — the originating run, an asset, a work order, or the SOP that should have prevented it.
3. 3

   Act

   Capture the corrective action (fix the immediate problem) and the preventive action (stop it happening again). When the work is done, move the incident to Awaiting verification.
4. 4

   Verify & close

   A manager reviews the evidence and closes the incident. A later effectiveness check confirms the preventive action actually held — if it did not, the CAPA can be reopened.

Regulator report & recurrence

A closed CAPA can be exported as a formal regulator report for MENA authorities. The exported PDFs — the register (the whole queue) and each per-incident audit file — render Arabic correctly, right-to-left, so a record you hand an inspector reads properly instead of as broken glyphs. Mihwar also clusters recurring incidents so a pattern across branches — the same failure, the same asset, the same root cause — is visible rather than buried in a list.

From the owner dashboard

The owner dashboard shows a CAPA rollup by branch. Clicking a branch in that rollup opens the inbox already filtered to that branch, with a visible filter chip you can clear — so a number on the dashboard takes you straight to the incidents behind it, scoped to what you're allowed to see.

Templates & settings

Admins configure CAPA behavior — severities, auto-escalation thresholds, and report templates — under Settings → CAPA templates. The background workers that auto-create and escalate incidents report their status on the worker health page.

Permissions — who can do what

• capa:read — view the queue and incident detail. Default for branch and warehouse staff.
• capa:write — add notes, attach evidence, and transition through investigation (everything except verify and close).
• capa:manage — verify and close incidents, edit templates, and override owner or due date.

Branch and warehouse users see only the incidents tagged to their assigned locations.

FAQ

Do I have to create CAPAs myself?

Rarely. The common ones open automatically from a checklist fail, a quality breach, a receiving discrepancy, or a recurring equipment issue. You create one by hand only for something you noticed that no check caught.

Why can't I close my own CAPA?

Closing requires capa:manage, which is usually a QA manager or org admin. If you investigated and fixed the issue with capa:write, move it to Awaiting verification and a manager will verify and close it — that second set of eyes is the point.

What is the effectiveness check?

A scheduled look-back after closure that asks “did the preventive action actually work?” If the problem came back, the CAPA is reopened rather than left falsely closed.