Projects, Tasks & Time Tracking

1. Projects as Containers for Work

Projects are the top-level organising unit for work in SamvraCore, surfaced through ProjectsPage and a dedicated ProjectDetailPage. A project groups related tasks together and carries its own status tracking, so the state of an initiative can be read at the project level rather than only by inspecting each task underneath it.

Projects are a full CRUD resource: they can be listed, created, opened for detail, updated and deleted through the projects API. The detail page is where a project's tasks and progress are reviewed in one place, giving a single view of everything happening within that body of work.

Projects also reach beyond the task module. In time tracking, a time entry can be associated with a project, and billing rates can be defined per project. This means a project is not merely a folder for tasks; it is also a cost and billing dimension. Work logged against a project can be rated at a project-specific billing rate, which is what allows the organisation to turn recorded effort into billable value for that specific engagement.

Because projects sit above tasks and are referenced by time entries and billing rates, they are the hinge between the planning side of the system (what work exists and what state it is in) and the measurement side (how much time that work consumed and what it is worth). Keeping the project as a first-class, independently tracked entity is what makes both of those readings possible from a shared structure.

2. The Task Lifecycle and Status Workflow

Tasks are the unit of actionable work, managed through TasksPage. Each task is assignable, carries a priority level, and moves through a defined status workflow rather than a free-text state.

The task lifecycle has four stages: To Do, In Progress, Review, and Completed. Work flows from To Do into In Progress, then into Review, and finally to Completed, giving a consistent progression that every task follows. A dedicated status endpoint updates a task's status, so moving a task along the workflow is an explicit, tracked operation.

Priority is expressed on a four-level scale — Low, Medium, High and Urgent — letting teams distinguish routine work from items that need immediate attention. Tasks are assigned to team members so ownership is always clear, and each task can carry a due date. The system detects overdue tasks and exposes them through a dedicated overdue view, so deadlines that have slipped are not buried.

Full CRUD operations are available on tasks, and the status, assignee, priority and due-date fields together give a task enough structure to be scheduled, prioritised and tracked. Because status changes are first-class operations rather than ad-hoc edits, the workflow stays meaningful: a task's position in the To Do to Completed sequence genuinely reflects where the work stands, which is what makes the board views and reporting trustworthy.

3. Task Collaboration — Comments, Reactions, Ratings and Tags

Tasks are collaborative objects, not just assignment tickets. Several features turn a task into a place where a team communicates and gives feedback.

Comments are threaded and support at-mentions, so team members can hold a discussion directly on a task and pull specific colleagues into it. Comments can be added and deleted through the task comments API.

Reactions let people respond with emoji on both tasks and comments, providing lightweight acknowledgement without a full written reply. Reactions can be added and removed, and they exist at two levels — on the task itself and on individual comments.

Ratings apply a five-star system to tasks, with an average and a count displayed. This gives a quantified quality or satisfaction signal on completed work, which the team can read at a glance.

Tags provide a flexible categorisation layer, letting tasks be labelled and grouped across projects according to whatever scheme a team adopts.

These collaboration features share the task's organisation scope and sit alongside its workflow, so a single task record carries both its formal state — status, assignee, priority, due date — and the human layer of discussion, reactions, ratings and labels. That combination keeps the conversation about a piece of work attached to the work itself, rather than scattered across separate messaging tools.

4. Board Views, Personal Queues and Status History

Beyond editing individual tasks, SamvraCore offers several ways to see tasks in aggregate, each driven by the same underlying task data.

The Kanban board presents tasks as a visual, drag-and-drop board with four status columns matching the lifecycle: To Do, In Progress, Review and Completed. Dragging a card between columns is the visual equivalent of the status-update operation, so the board is a direct manipulation view of the workflow. The board is served by an endpoint that returns tasks grouped by status.

Two personal and exception views help individuals focus. A my tasks view returns the current user's own tasks, and an overdue view surfaces tasks whose due dates have passed. Together these let a person see what they own and what is late without manually filtering the full list.

Every task also keeps a status history: a complete audit trail of status changes, each recorded with a timestamp and attributed to the user who made the change. This history can be retrieved per task, giving an accountable record of how a task moved through its lifecycle and who moved it.

These views matter because they turn the structured task data into something a team can actually run from day to day. The board drives flow, the personal queues drive individual focus, and the status history provides the accountability that makes the whole workflow auditable after the fact.

5. Time Entries — Recording Work

Time tracking begins with the time entry, managed through TimeEntriesPage. A time entry records effort spent and can be associated with a project, a task, or a customer, so logged work can be attributed to whichever dimension matters for a given engagement.

Each entry classifies work as billable or non-billable, which is the distinction that later determines whether the time contributes to an invoiceable total. Entries carry a description and notes so the nature of the work is captured in words, not just hours. The duration itself can be supplied either as a direct duration or by entering start and end times, accommodating both after-the-fact logging and clocked work.

Time entries are full CRUD resources, so they can be created, viewed, edited and deleted as an individual corrects or refines their record. Because an entry can point at a task, the time-tracking layer connects directly to the task workflow described earlier: the same task that moves through To Do to Completed can accumulate the hours spent driving it there.

This association is what gives the later stages their meaning. A customer-linked billable entry can flow toward billing, a project-linked entry contributes to that project's effort totals, and a task-linked entry ties cost back to a specific deliverable. The time entry is therefore the atomic fact from which timesheets, billing and reporting are all built, which is why its project, task or customer association and its billable flag are captured at the point of entry.

6. Timesheets and the Approval Workflow

Individual time entries are consolidated into timesheets, managed through TimesheetsPage and a TimesheetDetailPage. Timesheets are organised by period and are typically weekly, grouping a person's entries for a span of time into a single reviewable document.

Timesheets follow a submit-and-approve workflow. The owner submits a timesheet for approval, and a manager can then approve or reject it. Each of these transitions — submit, approve, reject — is an explicit operation, so a timesheet's state reflects a deliberate action rather than a passive edit.

To make review manageable at scale, a Pending Approvals queue (PendingApprovalsPage) collects the items awaiting a decision, so an approver can work through outstanding timesheets in one place instead of hunting for them. This mirrors the centralised approval pattern used elsewhere in the system for documents such as leave requests and expense claims.

The approval step is what gives recorded time its authority. Until a timesheet is approved, the hours on it are provisional; approval converts them into an accepted record of work. Because timesheets are built from the underlying billable and non-billable time entries, approving a timesheet effectively signs off on the billable total that will feed downstream billing and reporting. The period-based organisation keeps this review on a regular cadence, so time is confirmed in orderly batches rather than entry by entry.

7. Billing Rates and Time Reporting

The final piece of time tracking turns confirmed hours into value and insight through billing rates and time reports.

Billing Rates (BillingRatesPage) define the monetary rate applied to time, and they can be set at several levels: per user, per project, and per customer. Rates also carry effective dates, so a rate change takes effect from a point in time without rewriting history. Crucially, the module provides an auto-calculate capability, which is what applies the appropriate rate to recorded time to derive a billable amount rather than requiring manual computation. Billing rates are full CRUD resources, so an organisation maintains its rate card directly within the module.

The layered rate structure means a single logged hour can be valued according to who performed it, which project it belonged to, or which customer it served, giving flexibility in how different engagements are priced.

Time Reports (TimeReportsPage) provide trend analysis over the recorded data, letting the organisation see how time is distributed and how it changes over time rather than only reading raw entries.

Read end to end, the time-tracking module forms a pipeline: entries capture work and mark it billable or non-billable, timesheets batch and approve that work by period, billing rates value the billable portion through auto-calculation, and time reports surface the trends across the whole. Each stage depends on the fidelity of the one before it, which is why accurate association and classification at the time-entry stage ultimately determines the quality of both the billing figures and the reporting.