When the change was not a person
Every automated change names what caused it
A ticket moves to a tech nobody picked. An invoice goes overdue at eight in the morning. A reason for each of those exists, and the question is whether it lives on the record or in somebody's head. This guide walks the same mechanism across four record types on one instance: a ticket, an invoice, an assistant action, and the ledger the engine keeps.
What you will have
- A ticket whose history names the behaviour that assigned it, beside the row that names the person who reassigned it after.
- An invoice whose status says Overdue and, next to it, which job decided that.
- The same card on the same record naming a human, a scheduled job and an assistant action, each in its own vocabulary.
- A list of every decision the engine made, so the same event can be read from the rule's end as well as the record's.
- A plain account of where the reason is recorded today and not yet shown.
Why it works this way
The row is named by what acted, not by whoever held the session. A job that runs at eight in the morning has no person behind it, so the row carries the job's name instead of borrowing one. When a person is genuinely involved, they are named after the thing that acted, never instead of it.
Every record type uses the same card, because there is one history panel and one cause field behind it. A ticket, an invoice, a quote, a document, a vault entry, a subscription and a domain all render the same rows from the same column. That is why the vocabulary does not change when you move from the service desk to billing.
The reason and the change are one entry. Opening the row shows what moved and what decided it in the same box, so nobody has to line up two logs by timestamp.
This is worth trying on whatever you run today. Pick one record that changed while nobody was looking and ask the record what changed it. Either the answer is on the record, or somebody has to remember it.
Steps
Open a ticket that was assigned without anyone picking a tech, then open History in the right column.
Two rows, two vocabularies. The lower row reads "system", then "Autonomous dispatch", then "to jordan.reyes", then "Dispatched". The row above it reads "user", then "Northwind Demo", then "Reassigned". One names a behaviour and the tech it picked; the other names a person. Nobody has to work out which was which.
Open a ticket that was assigned without anyone picking a tech, then open History in the right column. Open a different ticket and read the same card.
Here the machine row reads "SLA self-acknowledged: creator took the assignment", with "for Northwind Demo" after it and "SLA self acknowledged" as the change. A whole sentence, not a code. The clause after the name is the person the row is credited to, which is why it reads "for" here and "to" on a dispatch row.
Open a different ticket and read the same card. Leave the service desk and open an invoice that went overdue on its own.
The status badge reads Overdue. Right beside it, in the same line, it reads "via Invoice overdue sweep". That is a different record type, a different area of the product and a different kind of behaviour, and the answer is in the same place: next to the value it explains.
Leave the service desk and open an invoice that went overdue on its own. Scroll to History on the same invoice.
Three rows tell the whole life of the money. "system", "Recurring billing engine", "Created pending" at the bottom. "user", "Northwind Demo", "Approved" in the middle. "system", "Invoice overdue sweep", "Marked overdue" on top. A run made it, a person approved it, a job flagged it, and the record says which was which without anyone writing a note.
Scroll to History on the same invoice. Click the top row.
It opens in place: Due Date, Sep 16, 12:00 AM. Trigger, overdue-sweep. Invoice Number, 14. The reason and the facts it acted on are one entry, so the question "what did it look at" does not need a second screen.
Click the top row. Open a ticket an assistant has touched.
Five rows, three kinds of actor, one card. Three rows tagged "elise" name the capability that ran, "Explain why something happened (diagnostic)", and credit the person who asked with "for help+kb1". Under them a row tagged "system" reads "Dedicated tech (Client default assignee)". Under that, a row tagged "user". An assistant action is recorded the same way a scheduled job is, and it says whose request it was.
Note: The grey text at the end of an assistant row is the capability's own key, not a phrase. It is the one row type where the machine name shows through.Open a ticket an assistant has touched. Read the same events from the other end: Automations, then History.
In-flight sequences at the top, waiting on nothing here. Run History under it, with the automation, the status, when it started and how long it took. Under that, the decision ledger: when, which automations decided, the subject, the event, the outcome and the ticket. The newest row names "Dedicated tech assignment" and "Elise checklist auto-attach", Ticket Created, Acted. The record says which behaviour changed it, and this page says that behaviour ran.
Read the same events from the other end: Automations, then History. Devices carry the same chip on their own timeline.
A device's Activity tab merges portal actions with what the agent reported, and an automated row carries the same "via" line beside the actor. It is not pictured here because this instance has no enrolled device, and a frame of an empty roster would prove nothing.
Exports carry the reason as a column.
The ticket export and the invoice export both have a column headed Why, and the cell holds the same sentence the screen shows. A spreadsheet handed to somebody outside the portal keeps the reason attached to the row instead of losing it at the door.
Know where the reason is recorded and not yet shown.
This is the honest half. A timer stopped by the midnight cutoff or the reaper records its reason, and the time entry itself has no history card to show it on. A portal user changed by the client-owner sync records its reason the same way, with the same gap. On the audit log list, an automated row shows the word System and the time rather than the name of the behaviour, so the list tells you it was not a person without telling you what it was. Where tags appear on a record, the reason is there but it is a hover, which means it is not on screen until you go looking. None of this is a plan or a date. It is what the product does today.
Note: Nothing on this page is a roadmap. Each step describes what one instance shows right now.
The pages behind each click
Other ways to do this
Start from the behaviour instead of the record
Open Automations, then Library, and pick any row tagged Setting. The line under the rule's name links back to the page that controls it.
Filter the audit log by action
Open System Logs, then Audit Log, and use the action picker. The automated actions carry their own names, so TIMER_AUTO_STOPPED and INVOICE_MARKED_OVERDUE can each be listed on their own.
If it did not work
- The History card looks empty: it ships collapsed. Click the card's own header to open it.
- Every row names a person: then a person made every change on that record, which is exactly what the rows are telling you.
- A row names a behaviour but has no link: a source with no page to open renders as words rather than a dead link. A dispatch row and a settings-driven row behave differently here on purpose.
- The row you want is older than the retention window: the card ends with a month picker and a Load button that fetches from the archive.
- You cannot find the reason for a stopped timer on the time entry: it is recorded, and today the only place it can be read is the audit trail. See step 10.
Questions this page answers
What does History track?
History has three parts. In-flight sequences lists multi-step rules that are waiting on their next step. The run table lists recent runs with the name, the status, the start time, and how long each took. Under it, the decision ledger shows what the engine read and what it chose. Sort any table by a column to find what you need.
Was this helpful?