Add notes and maintain the Repair Order

A Repair Order has no single notes box. Notes attach to the thing they describe: a Service, a Sublet, the customer record, the vehicle record, a time entry. Each kind has its own audience, and knowing which ones the customer can see is the difference between a helpful note and an awkward phone call. This page maps every note surface, explains the Activity card, and covers correcting the Repair Order's customer, vehicle, and details while work is open. Corrections after the Invoice is finalized are covered in the Corrections and Recovery section, and the four intake fields have their own reference in Set the Reason For Visit, Visit Type, odometer, and Promise Time.

Every note on a Repair Order, and who sees it

Note	Where you write it	Who sees it
Internal notes (Service)	Service card, Estimate tab	Staff only. Never on the Customer Portal, never on the Invoice.
Customer notes (Service)	Service card, Estimate tab	The customer, on the portal Service card under Notes, once the Service is Sent. Not printed on the Invoice.
Why this is needed (Service)	Service card, Estimate tab	The customer, on the portal Service card. Not printed on the Invoice.
Customer notes (Sublet)	Sublet row, under the Sublet name	Printed on the Invoice as the line's description. Not shown on the portal.
Notes (customer record)	Customer page, or Edit customer on the RO Overview	Staff only. Shown read-only on the Overview customer card.
Internal notes (vehicle record)	Vehicle edit dialog, or Edit vehicle on the RO Overview	Staff only. Shown read-only on the Overview vehicle card.
Notes (time entry)	Work tab time log	Staff only. Shown in the entry's timeline.
Internal notes (appointment)	Appointment form	Staff only, and only on the appointment.

The three Service note fields live at the bottom of each Service card on the Estimate tab and autosave as you type. Internal notes is the staff scratchpad for that Service: sourcing details, "customer declined this last visit", whatever the next person needs. Why this is needed is the customer-facing justification, the benefit or risk that sells the work. Customer notes carry any other customer-facing detail. The last two reach the customer only when the Service has been Sent to the portal, so you can draft them freely while the Service is still being built.

Two consequences of that table are easy to miss:

• Nothing you type in a Service note prints on the Invoice. The Invoice prints Service names and line descriptions (labor descriptions, part details, Sublet customer notes). If a sentence must survive onto the bill, put it in a line description, not a note. See Complete, cancel, restore, print, or prepare a Repair Order for invoicing.
• Technicians working from the Work tab do not see Service notes at all; the note fields are on the Estimate tab. A note a technician must read before starting is worth a spoken word or a text until then. The Work tab's own writing surface is the optional note on each time entry, in Track Service progress and work time.

There is no document-level notes field on a Repair Order. An Estimate has one (the Internal Notes card on its overview), but it stays behind on the estimate when the estimate converts; open the original estimate from Estimates to read it. Appointment internal notes stay behind the same way: check-in carries the Reasons For Visit, Visit Type, Promise Time, and service advisor onto the Repair Order, not the notes. Re-enter anything that still matters as a Reason For Visit or a Service internal note.

What your staff observed about the vehicle is not a note in this sense. Inspection findings and Technician Concerns have their own capture flow, ratings, and media, covered in Record Technician Findings, notes, and media. Notes alongside customer Conversations in the Inbox are a planned feature and not available yet; what the Inbox does today is covered in Use templates, quick replies, and internal notes.

All of these notes freeze together with the rest of the estimate content when the Repair Order reaches a terminal state: Invoice finalized, closed without sale, or voided. After finalization, changing a note means reopening the Invoice first.

The Activity card

The Activity card at the bottom of the Overview tab records meaningful changes to the Repair Order, each with the User who made it and when. It loads the newest events first, has a search box for filtering by a name or detail ("promised", "brake", a technician's name), and a Show older button for the rest.

What lands in it, broadly: changes to the visit facts (Visit Type, odometer, Promise Time, service advisor), Reasons For Visit with the text quoted, Service changes (created, renamed, notes edited, marked reviewed, shown to or hidden from the customer, authorized with the amount, declined, completed, reopened, deleted), technician assignments, Workflow Stage moves, payments and voids, and lifecycle events such as approval requests sent, portal decisions, Invoice finalized, sent, or reopened, inspections completed, and the Repair Order closed without sale. Edits to the customer, contact, and vehicle records show up here too, so "who changed the plate" has an answer on the visit where it mattered. A note edit is logged as the fact, for example Updated service "Front brakes" internal notes, not the text that changed.

Two boundaries. It is per-RO, not shop-wide: you cannot pull one User's activity across all Repair Orders, as covered in Review login and permission history. And the customer never sees it: the Customer Portal shows its own milestone timeline built from a short fixed list of events, not this log.

Keep the visit facts current

Mid-job maintenance happens on the Overview tab. The Visit Details card holds the service advisor, technician, Visit Type, and Promise Time behind its Edit button; the odometer readings live behind the gauge button in the page header. Each of these has a page that covers when and why to change it: Assign service advisors and technicians for the people, Set the Reason For Visit, Visit Type, odometer, and Promise Time for the visit fields, and Move work through Workflow Stages for the board position. Every one of these changes is logged in Activity, so keeping them current costs nothing in traceability.

Correct the customer or vehicle while work is open

Wrong details on the right records is the common case, and it is fixed in place. Edit customer on the Overview customer card opens the customer record itself: name, contact details, notes. Edit vehicle does the same for the vehicle: VIN, plate, engine, color. These edit the shared records, not a copy on the Repair Order, so the correction shows up everywhere the customer or vehicle appears, and it is logged in this RO's Activity. See Create and manage personal and business customers and Add vehicles and correct vehicle information.

The wrong record entirely is a different problem, and it has its own button. Change customer and Change vehicle, beside the pencils on those same two cards, re-point the Repair Order at different records rather than editing the ones it already has. Because a vehicle belongs to one customer, the two live in a single dialog: choosing a different customer clears the vehicle so you pick the right car for the new owner, and it also clears the RO's Preferred Contact. An Estimate has the same two buttons, so identity mistakes caught before conversion stay a ten-second fix. Deleting and starting over is still the cleaner move when nothing on the RO is worth keeping; the delete flow has a "created by mistake" reason and keeps an audit trail, see Complete, cancel, restore, print, or prepare a Repair Order for invoicing and Create or convert a Repair Order.

Related record problems have their own pages. A vehicle that changed hands cannot be transferred while this Repair Order is open, which is by design; see Transfer a vehicle to another customer. Two records for one physical vehicle is a merge, in Find and resolve duplicate customers or vehicles. And once the Invoice is finalized, both Change buttons are disabled, because changing the customer or vehicle is then a correction with accounting consequences, owned by the Corrections and Recovery section.