Putting a change back

Every repair order keeps a running list of what happened to it, in the Activity panel down the side of the ticket. Some of those lines can be put back. Most cannot, and the ones that cannot say so in a sentence where the button would have been, rather than leaving you hunting for a control that was never there.

A customer record keeps a shorter list of the same kind, called Edits to this record, on its Customer info tab. It holds the last five saves somebody made to the record and works the same way. Those are the two screens that carry this; there is not a third.

This is not the trash. The trash brings back a record somebody deleted. This brings back a value somebody changed — the promised time, who owns the ticket, whether a job is approved. Two different mechanisms for two different mistakes, and neither one covers the other.

The things that go back

• The promised time — the article on promised time covers what it feeds.
• Who owns the ticket, when it was handed to the wrong advisor.
• What the ticket is waiting on — the hold you put it into.
• A job moved to awaiting approval, approved, declined, or deferred. Four of the seven on a ticket are these.
• An edit to a customer record — the name, the company, the fleet and tax-exempt switches, the notes, the addresses, the contact preference, the language, the DOT number, the referral source and the tags.

That is the whole list, and it is a list rather than a rule because each one had to be written: putting a job's authorization back also moves the ticket's totals, the way authorising it forward did. Nothing was added to the list by accident, and nothing falls onto it by resembling something on it.

Doing it

1. 1

   Step 1: Find the line on the ticket's Activity panel, or on the customer's Edits to this record

   Both show the five most recent lines. If what you want is further back, see the boundary at the end of this article — the strip is where the control lives, and it does not follow you to the audit trail.

2. 2

   Step 2: Type why

   A box appears under the line reading Why is this going back?. It is required. Leave it empty and the screen comes back with Say why this is going back — a revert with no reason is a change nobody can explain later. Five hundred characters is the ceiling.

3. 3

   Step 3: Press Put back

   The value returns to what it was, and a new line appears above the old one with your name, the time and your reason on it. The original line does not move, change, grey out or disappear.

Afterwards the old line carries a note reading like Dana put this back on Friday at 5:53 PM — wrong ticket. Both entries stay on the strip for good. Nothing is collapsed and nothing is hidden, so a person reading the history in six months sees the mistake, the correction and the reason, in that order.

A change can be put back once, ever. Two advisors pressing the button in the same second produce one revert, not two — the database holds that, not the screen.

Who can press it

Whoever could have made the change in the first place. Putting a promised time back needs the scheduling key, the owner and the hold need the repair-order key, a job's authorization needs the estimates key, and an edit to a customer needs the customer key. That is deliberate rather than tidy: front desk can move a promised time and cannot open a repair order, so gating the undo on the repair order would have given them a mistake they could make and could not fix. If you lack the key, the line says You can't change the promised time on a ticket, so you can't put one back either. — and on a customer record it names the record it is about instead.

Nothing automatic ever reverts anything. Not a scheduled job, not an integration, and not the assistant — there is no version of this call a machine can make, and the refusal fires before anything is even read. The rule is the same one in the assistant article, enforced one layer deeper.

What may never be put back

Four classes, and they are the point of the feature rather than an apology for it. Anything a customer signed. Anything that moved money. Anything already sent outside the building. And anything whose undo would contradict a record that only ever appends.

Each one is a sentence on the row, and the sentence tells you what to do instead. These are the ones you will actually meet:

• The customer signed this. A signature is not ours to take back — talk to them and record what they decide.
• This moved money. Money is corrected with a new entry — a refund or an adjustment — never by editing the ledger.
• An invoice is a document the customer has. Void it and issue a new one rather than editing this.
• That estimate has already gone to the customer. Send a new version rather than editing this one.
• Deleted things come back from the bin — open /trash.
• A corrected punch is superseded by the next correction, never rewritten — it is pay evidence.
• That order has gone to the supplier. Call them — a button here does not un-order a part.
• That link is already with the customer. Revoke it — a revoked link is the honest undo.

The invoice one means what it says, and the control it points at is on the ticket you are already looking at: Void this invoice…, down the right-hand rail, offered to anybody who can take a refund. It asks you for a plain-language reason, and a reissue is refused until the invoice it replaces is void, so that order is the whole path rather than a suggestion. What it will not do is unwind money that has already changed hands — while a payment or a tip still stands against the invoice the fold is not drawn at all, and the action behind it refuses as well. Refund or return that through the tender it came in on first, and the void is there.

Two are worth understanding rather than just reading. Moving a ticket between stages is refused because a stage change tells your integrations the car moved and invoicing mints a document — so you move the ticket where it should be instead, forward. Completing an inspection loses the same argument: the report is already in front of the customer, and you re-open the inspection on the DVI rather than un-completing it.

Where another undo already exists, the sentence points at it rather than shrugging. A delete says to open Trash, a merge says the absorbed record is waiting there, and an import says the import screen has its own undo. Two undo mechanisms for one action would drift apart, so there is only ever one.

Anything not named anywhere gets the house sentence: There is no automatic way back from this one. Make the change again by hand and the trail will show both. Every row gets something. Silence is not one of the options.

When it says the world moved on

A change that could be put back in principle is still refused if putting it back would quietly overwrite somebody else. The check is not one comparison but three: whether anyone did the same thing again since, whether the value itself still reads the way the entry left it, and — for the promised time, which keeps its own history — whether any later promise change landed from any source at all.

So a promise moved from Tuesday to Wednesday and back to Tuesday reads untouched, and is refused anyway, because somebody plainly worked on it after you. What you see is a named sentence rather than a generic error — Dana changed the promised time after this. Putting this back would undo their change too, so nothing was changed. A promise that has moved since counts the moves: The promised time on RO-0142 has moved twice since this. Putting this back would undo those moves too, so nothing was changed. An owner reads RO-0142 has been handed to somebody else since. Nothing was changed., and a job that has been touched again is named in the sentence.

On a customer record the question is asked FIELD BY FIELD, because one save can move twelve of them. Somebody tidying the tags on Tuesday does not make Monday's misspelled street permanent — only a later change to the SAME field refuses, and the sentence names which one: The company on this customer has changed since. Putting this back would undo that change too, so nothing was changed. Merging two records counts as a change to every field, because a merge does not record which columns it moved.

Fourteen days is the outside limit. Past it the line reads This is more than 14 days old. Make the change by hand — the trail will show both. Note that this is a different window from the trash's thirty days, and deliberately shorter: a deleted customer sitting in a bin harms nobody, and a promised time silently reverting a fortnight after the car went home is a phone call you did not expect.