Find out what happened without asking anyone
Recorded workspace actions are written to an append-only log with the action, the person who performed it, what it was performed on and when. Where before and after snapshots exist, the fields that actually changed are shown as old to new.
Viewing the log requires an explicit permission — it is not implied by being an admin.
The problem
Reconstructing an incident from memory does not work
Something went wrong three weeks ago. Two people remember it differently, both sincerely, and the only record is a chat thread that has scrolled past ten thousand messages.
- The current state of a record tells you where things ended up, not how they got there.
- A field that was changed and changed back leaves no trace at all.
- Nobody can say who reassigned the task, or when, so the conversation becomes about people rather than about the process.
- A customer dispute turns on a date nobody can evidence.
- The people who would know have left, and the knowledge left with them.
How TaskIt handles it
An append-only record of what the system tracks
Each workspace keeps its own audit trail. Entries are written as actions happen and are never edited afterwards — which is the only property that makes a log worth consulting.
- Every entry records the action, the acting user, the target entity, the IP the request arrived from and the time.
- Newest first, so an investigation starts where investigations actually start.
- Where a row holds both a before and an after snapshot, the fields that changed are rendered beneath the target as old to new — a rename shows both titles, a settings edit shows only what moved.
- Creation rows carry no before snapshot and correctly render no diff, rather than a fabricated one.
- Reading the log requires the audit permission on your role. An Admin base role does not grant it implicitly.
What you get
Disputes end in evidence
A recorded action with a timestamp settles a disagreement in a way that two confident recollections never will — and it does it without anyone having to be accused of anything.
Changes explain themselves
Seeing that a title changed is much less useful than seeing what it changed from and to. Where the snapshots exist, the diff is rendered rather than left for you to infer.
The record is not a permission everyone has
The audit log is where the workspace’s history lives, so seeing it is its own permission. Granting reporting access does not quietly grant this.
It cannot be tidied up afterwards
The log is append-only. Nothing in the product edits or removes an entry, which is precisely why it can be trusted about the moments that matter.
How it works
In the order a person using it meets them.
- 1
People work normally
Nobody records anything. Entries are written by the server as the tracked actions occur.
- 2
You open the log when a question arises
The tenant audit log lists recorded actions newest first, with the acting user and the target on every row.
- 3
You read the diff, not just the event
For rows with before and after snapshots, the changed fields are shown as old to new beneath the target — so you can see what a change actually did.
- 4
You cross-check with the task timeline
Each task also carries its own activity trail: accepts, progress updates, comments, handovers, reviews, joins and leaves. The audit log answers "who did this to the workspace"; the timeline answers "what happened to this task".
A three-week-old question, answered in two minutes
A customer says they were told the work was finished on the 4th. The team says the 6th.
- 1
Open the task
Its ID never changed, so the whole history is on one record however many people held it.
- 2
Read the timeline
Accepted on the 2nd, progress updates on the 3rd, a handover on the 4th, submitted on the 5th, approved on the 6th.
- 3
Read the handover
The 4th entry records what was completed and what was pending — which is what the customer was told, and it was not "finished".
- 4
Check the audit log
The handover entry names both people and the exact time, independent of anything either of them now recalls.
The result
The answer is a date with a record behind it, and nobody had to be asked to remember anything.
What is recorded today
Being specific matters more here than sounding comprehensive. The actions currently written to the audit log are:
- Task creation, handover, unable-to-complete and title change
- Creator notes — created, updated and deleted
- Bulk user import
- Onboarding completion
- Scheduled report configuration — created, updated and deleted
What is not recorded, and why you should know
Coverage of write actions is not yet complete, and expanding it is planned rather than done. Anything performed outside the API — a direct database script, for example — is not audited at all, because the audit is written by the application and a script bypasses it. A log that overstated its own coverage would be worse than one that states its limits.
The task activity timeline
Separate from the audit log and broader in what it records: created, assigned, accepted, progress updated, commented, attachment added, handover, review requested, approved, rejected, completed, reopened, status changed, joined and left — each with a timestamp, on the task itself.
A note on recorded IP addresses
The address stored on each entry is the one the application receives. This deployment sits behind a CDN, which means the recorded value identifies the edge the request passed through rather than the visitor’s own address. It is useful for rate limiting; it is not an identifying trail, and it should not be presented as one.
Frequently asked questions
No. The audit trail is append-only — nothing in the product edits or removes an entry. That is the property that makes it worth consulting when something is disputed.
Only roles that hold the audit-view permission. It is an explicit permission rather than something granted by being an administrator, so it can be given to exactly one person if that is what you want.
Not yet. The current set covers task creation, handover, unable-to-complete and title changes, creator notes, bulk user import, onboarding completion and scheduled report configuration. Broader coverage is planned. Separately, each task carries its own activity timeline, which records a wider set of task-level events.
Task history, comments, activity and audit logs are never removed by any automatic cleanup — the only thing any retention rule ever deletes is stored files. Lifetime data history is included on every plan term.
Where to go next
The capabilities either side of this one, and the problems it is bought to solve.
See the trail your current setup does not leave
Run a week of real work through a workspace, then open the audit log and ask it a question you could not answer last month.