Concessions
Deviation requests with an approval chain recorded as plain text, not a modelled workflow.
Last updated 6 September 2026 · v1
Overview
A Concession is a request to accept a deviation from a requirement for a Product, Service, or Process — a formal way of saying "this doesn't meet the specification, but we're asking to use/accept it anyway" — recorded with a category, the person requesting it, and a decision.
Why it matters
Deviations happen; the risk isn't that they happen but that they go unrecorded, or that "who approved this and on what basis" becomes unanswerable later. A Concession record exists specifically to capture that decision — who requested it, what the current approval stage is, and (once decided) the decision notes and date — as a permanent record independent of whatever informal conversation led to it.
How it works
A concession is created pending, with an approver_sequence and current_stage describing who needs to approve it and where it currently sits in that sequence — both of these are plain text fields, not a modelled workflow engine, so the actual routing and enforcement of "who approves next" is a matter of convention and manual field updates, not something the application enforces automatically. It ends approved or rejected, with decision notes and a decision date recorded at that point.
This screen
The list page shows every concession with its number, category and status, filterable/sortable by date raised, status, or when the record was created/updated. The detail page shows the full record including the approver sequence and current stage; create and edit forms share the same fields.
Fields
- Concession number — required. This request's own identifying reference.
- Description — required. What's being deviated from and why.
- Category — required. One of Product, Service, Process.
- Requested by — required.
- Date raised — required.
- Approver sequence — free text describing who needs to approve this concession, in order. Not validated or enforced by the application — a convention, not a workflow.
- Current stage — free text describing where in that sequence the concession currently sits. Updated manually as it moves through approval.
- Status — one of
pending,approved,rejected. - Decision notes / Decision date — recorded once a decision is made.
Actions
Moving a concession to approved or rejected is a direct field edit, available to anyone with edit access to this register — the approver_sequence/current_stage fields describe an approval process for the humans involved, but nothing in the application enforces that the recorded stage has actually signed off before the status changes.
What happens next
Nothing else in the product reacts automatically to a concession's status. If a concession was raised because of a Non-Conformance Report, cross-reference the two by their own reference numbers — they aren't linked by a relational field.
FAQ
Can the approver sequence be more than one person? Yes — since it's a free-text field, describe as many stages as your process actually has (e.g. "QA Manager → Client → Project Director"); the application has no fixed limit or structure on it.