Skip to main content

Approve or Reject an Override Request

A compliance override request opens whenever a technician saves a charge event that fails one of the configured gates: missing or expired cert, top-off without a documented leak repair, or recovery without registered equipment. The event is held in a pending state until a supervisor decides.

Approve to record the override and post the event as compliant. Reject to void the originating charge event. There is no third option — pending requests don't time out.

Before you start​

  • You have compliance.view to see the queue.
  • You have the kind-specific approver permission for the request:
    • compliance.override_cert_gating — to decide cert-gating requests.
    • compliance.override_topoff_gating — to decide top-off-gating requests.
    • compliance.override_recovery_equipment_gating — to decide recovery-equipment-gating requests.
  • You are not the subject technician on the request. The four-eyes rule blocks self-decision.
  • You have a defensible reason for the decision, at least 20 characters long.

Steps​

  1. Open the queue

    Select Compliance Override Requests in the top navigation bar. The queue defaults to pending requests.

  2. Pick the request to decide

    Each row shows kind, subject technician, and request time. Select the View action for the request you want to decide.

  3. Read the context

    The request page lays out:

    • Request card — kind, subject technician, request time, gating mode at request time, and CFR references.
    • Gate failure context — the JSON snapshot of why the gate failed (e.g. cert expired three days ago, no recovery cylinder linked).
    • Originating charge event — event number, type, quantity in pounds, the unit, and current pending / void status.

  4. Decide

    In the right column:

    • To approve, type a reason (at least 20 characters) in the Approve card and select the green Approve button.
    • To reject, type a reason (at least 20 characters) in the Reject card and select the Reject & void event button.

    The browser confirmation dialog summarises the action. Confirm to commit.

What happens next​

  • Approve — the system writes a compliance_overrides audit row, links it to the request, and posts the originating charge event as compliant. The unit's leak-rate calc includes the event from this point on.
  • Reject — the originating charge event is marked voided. The void reason captures the rejection text. The event no longer counts toward the leak-rate calc.
  • The request flips from pending to approved or rejected. The decision time, decider, and reason show on the request page and on subsequent charge-event audit views.
  • The decision is final. There is no undo.

Common situations​

SituationWhat to do
The cert expired but the tech genuinely was certified at the time of workApprove. Reason: "Tech §608 cert was current on the work date YYYY-MM-DD; renewal landed in TuffOps three days late. Cert card scan attached on tech's profile."
The tech topped off a unit that was already on a leak repair episode that closed todayApprove. Reason: "Top-off occurred after episode #N closed at HH:MM the same day. Verified against repair record."
The recovery cylinder was hired for the day and never registeredReject. The hired cylinder needed a TuffOps record before use. Reason: "Recovery from rented cylinder serial X — not registered in TuffOps catalog. Charge event voided to keep audit trail clean. Tech briefed for next time."
The subject technician is yourselfYou cannot decide. The page shows a "Four-eyes blocked" alert. Ask another supervisor.
You don't have the right approver permission for the request kindThe page shows a "Permission required" alert with the missing key. Hand off to a supervisor who has it.

Troubleshooting​

The Approve / Reject cards don't appear.

Either the request is already decided, you're the subject technician (four-eyes block), or you don't have the kind-specific approver permission. The right column shows the reason — read the alert.

The Approve button submits but nothing changes.

Your reason is shorter than 20 characters. The textarea has a minlength set; the browser will refuse to submit without enough text. Add detail and try again.

I rejected by mistake.

There is no undo. The originating charge event is voided. To restore the operational record, the technician needs to re-record the charge event from a new work order line item. The void reason on the original event keeps the audit trail intact.

The decision shows the wrong supervisor name.

You're looking at someone else's decision history. The decided by field captures whoever submitted the form, not whoever opened the page. If a real attribution problem exists, the audit row in compliance_overrides is authoritative.