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 log lists recorded actions newest first, with the acting user and the target on every row. Because it spans tasks, people, sign-ins, schedules, files and billing, it can be narrowed to one kind of target — tasks, users, storage — and searched by action, person, target or IP.
- 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
Being specific matters more here than sounding comprehensive. The log spans task work, the people and access model, sign-in activity, schedules, files and billing — grouped below by the part of the workspace they belong to.
- Tasks — created, accepted, joined, left, handed over, marked unable to complete, and renamed; plus creator notes added, edited and removed
- People and access — bulk user import, role changes and deactivations, and refused attempts to grant access beyond your own or to remove the last administrator
- Sign-in and account — signing in, signing out, password changes, and an account being locked after repeated failed attempts
- Recurring schedules — created, updated and deleted, each generated run, and a schedule that stops after exhausting its retries
- Files and storage — files deleted, the retention policy changed, each automatic cleanup sweep, and uploads that were refused
- Workspace settings — onboarding completion, the Performance Analytics setting, scheduled report configuration, and Master Data imports
- Subscription — activation, plan changes, and seats requested and added
What is not recorded, and why you should know
Coverage is broad but it is not a guarantee of totality: not every write in the product leaves an audit row, so the log should be read as a record of the actions listed above rather than as proof that nothing else happened. Two limits are worth stating outright. 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. And failed sign-ins are deliberately not written one row per attempt; only the resulting lockout is, so that a stranger guessing passwords cannot fill your log.
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. The Audit Logs menu item appears only for roles on the Admin base.
Task work (created, accepted, joined, left, handed over, blocked, renamed, and creator notes), the people and access model (user imports, role changes, deactivations, and refused attempts to escalate access), sign-in activity (sign-in, sign-out, password changes and account lockouts), recurring schedules and their runs, files and storage (deletions, retention changes, cleanup sweeps and refused uploads), workspace settings, and subscription changes. It is not a guarantee that every write in the product leaves a row — read it as a record of those actions rather than as proof that nothing else happened. Separately, each task carries its own activity timeline covering task-level events in more detail.
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.