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 Carbon's non-conformance record, an NCR: a logged defect or deviation plus the work to resolve it. This page is the deep dive behind the quality overview. It lives in the quality module (there is no separate issue module), and every issue carries an nc-prefixed internal id plus a readable nonConformanceId you see in the UI.
An issue opens several ways: by hand from the issues list, from the shop floor in MES, from Slack, or automatically when an inbound inspection rejects a lot. Whichever door it comes through, it lands in 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 rigid state machine. It stores a rich-text issue template (the investigation write-up you start from) plus a preset priority, source, a list of required actions, and approval requirements. Picking a workflow when you raise an issue copies those presets in and drops the template into the issue's content.
This is how Carbon models the method: an "8D workflow" is just a workflow whose required actions cover the eight disciplines. A "containment workflow" is a lighter one. Nothing about 8D is hard-coded. You compose it from the same action building blocks as any other workflow, and you can build your own.
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.
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
An issue links to the documents and records it concerns through typed association tables. There are ten association types: items, customers, suppliers, job operations, purchase-order lines, sales-order lines, shipment lines, receipt lines, tracked entities, and inbound inspections. These are what let quality trace a defect back to exactly where it came from — a specific received lot, a specific job operation, a specific supplier — and what makes supplier quality a derived number rather than a scorecard you maintain by hand.
From the issue header you can also spin up a change order directly, carrying the issue across as its source, when the fix is an engineering change rather than a one-off disposition.