cypress.DOCS
Log inRegister
Cypress Docs
RemarketingReferenceClosing a sale

Issues, rollback & cancellation

When a closing goes sideways: filing Issues, unwinding steps, and cancelling with a culprit on record.

TL;DRAI summary

If a deal has a problem, you can raise an issue to track it. If a completed step in a deal turns out to be wrong, a Cypress Manager can roll back the deal to that step. If a deal falls through, a Cypress Manager can cancel it, stating why and what happens to the vehicle.

Dive deeper:

For: Everyone in a deal can raise problems · resolving them is CM-only

Deals genuinely fall through — financing collapses, a title is missing, a buyer goes quiet. Cypress doesn't treat that as an edge case: exceptions have their own machinery, and every one leaves a record.

Issues — the deal's ticket system

Anything wrong with a closing becomes an Issue on the deal's Issues tab. Seller, buyer, or CM can file one; each gets a ticket number (ISS-0001, ISS-0002, …), a category scoped to the step it concerns (payment problems, title delays, signature disputes, communication, SLA breach…), and a thread — messages with attachments, with the app tracking whose reply is awaited.

Three rules keep Issues honest:

  • Anyone files; only a CM resolves. Parties talk in the thread; the operator closes it as Resolved or Dismissed, and the filer is notified either way.
  • Every action on an Issue also lands in the closing's Activity tab — the ticket and the audit trail can never disagree.
  • An Issue doesn't pause the rail by itself. If the situation warrants stopping the deal, that's a rollback or a cancellation — below.

Rollback — rewinding the rail

Sometimes a completed step turns out wrong — funds were confirmed against the wrong deposit, a document was issued from facts that have since changed. A CM can roll the closing back to any completed step: everything after it re-locks, the target step reopens, its paperwork is superseded, live signing links are voided, and the responsible party is notified to redo it. A document step regenerates its paper on the way back, so the step reopens with the document waiting rather than an empty slot. The Commission Fee step and Vehicle Pickup are excluded — an issued invoice is corrected with a credit note, not by pretending it did not happen. The rollback itself is recorded on the process: who, when, from-step, to-step.

A late Deal Setup change: a Cypress Manager decides

Deal Setup stays editable to the end, and a correction there is not always harmless: changing a value that an already-issued document printed makes that paper wrong. A gate pass naming the wrong yard has to be made again, which means reopening the completed step that holds it.

Saving never reopens a step by itself. When a save changes a value that paper on a completed step printed, the closing names that step and a Cypress Manager decides:

  • A Cypress Manager who makes the change is asked straight away whether to reopen the step. Choosing Keep as issued leaves the paper as it is.
  • When a seller or buyer makes it, the change is saved, they are told that a Cypress Manager decides, and the Cypress Managers are notified.
  • On the closing, a completed step whose paper no longer matches the deal shows what it printed against what the deal says now. A Cypress Manager has Reopen step N right there; the reason is recorded with the rollback.

What never counts as a change to issued paper:

  • Filling in a box the paper left blank. Nothing the paper says is wrong. Answering a missing pickup address or ZIP while generating a gate pass does not touch a signed Bill of Sale that printed that box empty.
  • An edit undone. Changing a value and changing it back leaves the paper right.
  • A fact the paper does not print. Correcting a bank contact number does not affect a gate pass: the check is against each template's own fields.

Before a save, Deal Setup shows which documents print the facts being changed, whether any are signed and how many signing links are out.

Cancellation — ending the deal

Cancelling a closing is a CM-only decision with three mandatory facts:

  1. A reason — free text, on the record.
  2. A culprit — SELLER, BUYER, or NONE. This feeds the archive decision when penalties are on the table.
  3. A disposition — what happens to the vehicle:
DispositionVehicle goes to
Return to inventoryAPPROVED — relist when ready
Deal fell throughAPPROVED — relist when ready
Sold elsewhereARCHIVED, with the sold-elsewhere record
RemovedARCHIVED

Cancellation notifies both sides, writes the vehicle's Updates feed, and — because the deal's channel and offer survive as history — the analytics still count what happened honestly.

Worked example — the road not taken

Suppose Dan's financing had collapsed at step 5, with the check never clearing. Maria files ISS-0007 (Payment · funds not received) with the bank statement attached; the thread pings Dan, who confirms the bad news. Alex tries a rescue — nothing. He cancels: reason "buyer financing fell through", culprit BUYER, disposition Deal fell through. The Transit returns to APPROVED, relaunches the next morning, and Birchwood's record carries the cancellation. The real Transit never took this road — but every deal that does is exactly this visible.

Business rules

  • A cancelled closing stays readable forever — documents, Issues, and Activity included. Cancellation hides nothing.
  • Withdrawing the offer is not cancelling the closing: once a closing opens, the rail's exception paths are the only exits.
  • Culprit NONE is legitimate — force majeure exists; penalties don't apply to weather.
  • A vehicle with a cancelled Post-Sale deal re-enters inventory at APPROVED, never silently back to LISTED — a human relaunches it.

Under the hood

Issues are step-scoped incidents with threaded messages; rollback resets step state atomically and stamps the process with its last-rollback audit; cancellation maps disposition → vehicle status in one place. Integrators see CLOSING.CANCELLED with reason and culprit in the webhook catalog.