Issues (non-conformances)
How Carbon logs a non-conformance, drives it through a configurable workflow of actions and approvals, and dispositions the affected material before closing.
An issue is a non-conformance record containing a defect or deviation and the work required to resolve it. Issues belong to the quality module and carry an nc-prefixed internal ID plus the user-facing nonConformanceId. See the quality overview for broader module context.
Create an issue from the issue list, MES, or Slack. Carbon can also create one automatically when an inbound inspection rejects a lot. All sources use the same lifecycle.
The lifecycle
A nonConformanceStatus has three values. A new issue defaults to "Registered"; "Closed" is terminal and locks the record.
The header buttons drive these transitions, all gated by the quality update permission: "Start" (Registered → In Progress), "Complete" (In Progress → runs closeIssue), and "Reopen" (In Progress or Closed → Registered). The reopen path is why Closed isn't a dead end. It just re-opens the record for more work.
One issue, many pieces of material
The issue header holds the priority, source, type, and workflow. The affected material lives in a separate junction (nonConformanceItem), so a single issue can cover several items and several tracked lots or serials, each dispositioned on its own. The header status is not the same thing as a per-item disposition.
Header fields
Every issue carries a small set of classification fields. Type and location are required; the rest have defaults or are optional.
nonConformanceType) — your own list, not a fixed enum.nonConformanceWorkflow that pre-seeds the issue's priority, source, required actions, approvals, and a document template. See below.openDate is required; dueDate is optional; closeDate is stamped automatically on close.Workflows: the 8D and its cousins
A workflow is a reusable template, not a state machine. It defines initial rich-text content, priority, source, required actions, and approval requirements. Selecting a workflow copies those values into the new issue.
Carbon models as a workflow whose required actions cover the eight disciplines. 8D behavior is not hard-coded; custom workflows use the same action model.
Required actions and their system categories
Each issue references a set of required actions (requiredActionIds), and the moment the issue is set up, Carbon materializes one action task (nonConformanceActionTask) per required action, numbered by sort order. Those tasks are the checklist the team works through.
A required action can carry a systemType that classifies what kind of action it is. There are five:
The five system actions (Containment Action, Corrective Action, Preventive Action, Verification, Customer Communication) are seeded per company and protected: a database trigger blocks deleting them or changing their systemType, and each is unique per company. Any action you add yourself has no systemType and is fully editable.
Containment status is derived, not stored
The issues view computes a containment status from the action tasks. It reads "Contained" when a Containment-type task is In Progress or Completed, "Uncontained" when a Containment task exists but hasn't started, and "N/A" when the issue has no containment task at all. You don't set it. It follows the work.
Working the tasks
Action tasks run their own small lifecycle: "Pending" → "In Progress" → "Completed", with "Skipped" as an off-path exit. Tasks start Pending and do not auto-start. Completing a task stamps its completed date. A completed or skipped task can be reopened back to Pending. Tasks can be reordered, given due dates, and tied to specific processes, and a supplier-facing action task can be shared externally as a SCAR (Supplier Corrective Action Request) report.
The SCAR is a private, login-free link the supplier opens to respond. They see the non-conformance details, the current status, and the action tasks assigned to them — not the rest of the issue: dispositions, approvals, and closure stay internal. For each task the supplier can update the status and write notes in an editor that auto-saves as they type; entering notes on a "Pending" task promotes it to "In Progress" automatically. Once the issue is "Closed", the SCAR locks and the supplier can no longer make changes. Whoever holds the URL can open it, so send it only to the supplier contact.
Approvals and the Material Review Board
Beyond actions, an issue can require approvals. The only approval requirement Carbon ships is . Adding it materializes an approval task and, when MRB is newly required, seeds two reviewers with titles "Engineering" and "Quality". Remove MRB and those seeded reviewers are cleared; reviewers you added by hand are left alone. A reviewer is just a title on the issue. You manage the list inline on the issue.
Dispositions: deciding the material's fate
Closing an issue is where the affected material gets resolved. Each nonConformanceItem row carries a — the decision about what to do with that material. The database enum has more values than the UI exposes; the active picker is a deliberate subset of five:
A Pending disposition on linked material blocks closing
closeIssue runs a preflight over every affected-item row that has linked tracked entities. It refuses to close — "Cannot close: Disposition is still Pending" — if any such row is still Pending, if the linked quantities don't sum to the row quantity, or if a linked entity is missing or already Consumed. Only once the plan is clean does it stamp each entity's outcome and set the issue "Closed". A row with no linked material is not gated: you don't have to disposition what you never traced.
What an issue can point at
Typed associations link an issue to items, customers, suppliers, job operations, purchase-order lines, sales-order lines, shipment lines, receipt lines, tracked entities, and inbound inspections. These links provide traceability to the source record and support derived supplier-quality metrics.
From the issue header you can also spin up a change notice directly, carrying the issue across as its source, when the fix is an engineering change rather than a one-off disposition.