Time Approval
When time drives billing or payroll, someone has to sign off on it. TimeCampus puts a clean review loop on top of raw entries: a member submits a period, an approver approves, rejects with a reason, or requests a revision — and every decision is recorded, so nothing slips through and everything is auditable.
TimeCampus is generally available — create an account at app.timecampus.com.
Where it lives
Everything happens on the Time Approval page — submitters create and track their requests there, and approvers work their review queue on the same page.
The lifecycle
An approval request moves through explicit statuses:
| Status | Meaning | Who acts next |
|---|---|---|
| Pending | Submitted and waiting for review | The approver |
| Approved | Signed off, with optional notes | Nobody — the loop is closed |
| Rejected | Declined, with a required reason | The submitter (fix and resubmit) |
| Revision requested | Sent back with notes for specific changes | The submitter |
| Withdrawn | Pulled back by the submitter before a decision | The submitter (resubmit when ready) |
The lifecycle is guarded: a request that's already been decided can't be decided again, so there are no conflicting double-decisions.
Submitting your time
- Track your time as usual — see Time entries.
- On Time Approval, submit the period (for example, your week) for sign-off.
- Track the request's status from your own list — you always see exactly your requests, and the current state of each.
Made a mistake right after submitting? Withdraw the pending request, fix your entries, and submit again. You can only withdraw your own requests.
Reviewing as an approver
Approvers see the queue of pending requests on Time Approval and take one of three actions:
| Action | When | What's recorded |
|---|---|---|
| Approve | The time looks right | Approval plus optional notes |
| Request revision | Mostly right, needs specific fixes | Notes describing what to change; the request returns to the submitter |
| Reject | The submission shouldn't stand | A required reason — you can't reject silently |
Requiring a reason on rejection keeps the loop honest: the submitter always knows why, not just that.
Revision and resubmission
A revision request isn't a dead end — it's a round trip:
- The approver sends the request back with notes.
- The submitter corrects the underlying time entries.
- The submitter resubmits the period.
- The approver reviews again.
Each round is part of the request's recorded history, so the trail from first submission to final sign-off is complete.
Approvals, reporting, and sign-off
Approval is what turns raw tracked time into reviewed time:
- An auditable record — every submission and decision carries who, when, and why, backed by the platform's audit trail
- Confidence downstream — approved periods are the ones you can stand behind in reports, client billing, and payroll
- Stats across the lifecycle — roll-ups show how many requests are pending, approved, and rejected over a date range, so leads can see review health at a glance
Practically: settle the entries first, then submit. Edits belong in the revision loop, not after sign-off.
Access and scope
Approval requests are workspace-scoped, and role-based permissions decide who can submit and who can decide — see Access control. Submitters see their own requests; approvers see the queue they're responsible for.
Multi-step approval chains (routed through several roles) and notification-driven escalation are on the roadmap. Today the loop is a single submitter-approver round trip.
Next steps
- Time entries — the data you're submitting
- Reports — exporting reviewed time
- Team analytics — the aggregate picture approvals feed into