Every change in Quevell is recorded. Not selectively and not by configuration: the record is written by the same core that carries out the change, so no single feature can forget to write it.
What a record holds
One record is one change:
| Field | What it is |
|---|---|
| Scope | what happened, such as issue.transitioned or workflow.updated |
| Target | the type and id of what changed, and its version afterwards |
| Actor | who did it |
| Time | when |
| Change set | the values before and after |
| Result | SUCCEEDED: the trail records changes that happened |
| Chain | a correlation id, and the id of the event that caused this one |
| On whose behalf | if somebody acted under another user's name, both are recorded |
| Rule | if an automation rule acted, its id, its revision and the cascade depth |
The last two are worth reading twice. Signing in as another user is never silent: both names are in the record, and the user who was signed in as gets an email about it. And an automation rule's action is never dressed as a user's: the record names the rule and which revision of it fired.
The chain ties an effect to its cause. If one change triggered a rule and the rule changed something else, every link carries the same correlation id, and "why did this suddenly move" is one filter away.
Where to read it
The trail exists at two levels.
Issue history. On the issue itself, a feed shows what happened to it: field changes, transitions, labels, links, comments, attachments. That is what day-to-day work needs, and it is open to everybody who sees the issue.
What an automation rule did appears in the same feed, next to what people did, and is clearly marked as not a person's: where a name would be there is the rule's name and its revision, with a link to the rule for those who see it. The feed also tells you when the issue was created and last changed: the first row of the feed is its creation, and the last is whatever happened to it most recently.
The company's trail. Administration, the security section: every record in the company, with filters and paging. It requires the right View audit. Company administrators always have it.
Searching it
The company trail filters on four things, and they combine:
- actor: everything one user did;
- about: every record where a user is the actor, the subject of the change, or the person somebody signed in as;
- scope: one kind of change. The list of scopes comes from the product, so a scope is always spelled the way the product spells it;
- result: the filter exists, but today the trail holds only successful changes, so it narrows nothing.
Results are paged by cursor, newest first, and the total number of records is shown beside them, not the size of the page. That distinction matters: "how many times did this happen" used to be answered by the length of the first page, and the answer was always twenty-five.
What is not here
The trail records changes that happened. An attempt at something the user had no right to do never becomes a change and never reaches it: the person who was denied sees it, and so do the server logs, but not this trail.
Automation works differently on this point: a rule denied by permissions is recorded, in the automation Journal, which is a separate feed. See automation.
Records are never changed
A record is never edited and never deleted. The database itself enforces this: any attempt to change or remove a row fails with "audit events are immutable".
This matters more than it sounds. The ban lives on the table itself, so neither a bug in a new feature, nor a company administrator, nor anybody who obtains the application's own database account gets around it. While the company exists there is no tidying up after yourself.
There is exactly one exception, and it is the company's own deletion: a record can be removed only once the company it belongs to no longer exists. That is not a flag the application sets but a condition the database checks: erasing a trail means deleting the company first, which is not covering your tracks.
How long records live
The trail is not swept on a schedule and has no retention period after which records are dropped. A company's records live as long as the company does.
How long the company itself lives once people stop signing in is in Getting started: three months to the archive, and 30 days more before the data is deleted.