Skip to content
Log in Sign up

Projects, work, time and approvals on one model

Capabilities that only work properly together, which is why they share one model instead of an integration.

Seven modules, one permission model

Each one is a page. Projects and work items and Time tracking are on when you sign up; Boards, the Library and the AI assistant wait for an owner to switch them on.

Time tracking

Correct time beats convenient time. We accept some interface complexity to avoid an ambiguous timestamp.

A week in the LynxSprint timesheet grid A design representation, not a screenshot. Rows of work run down the grid and the five working days run across it, with hours in each cell. The four rows are Development and Code review against a client project and its work items, Meetings against internal work, and Administration against no project at all, because project and work item attribution is optional on every entry. A filled dot marks a billable row and a hollow one marks a non-billable row. Each day totals eight hours and the week totals forty. The week is in draft and can be submitted for approval. Week of 13 July Europe/London · business dates Draft Submit for approval Activity and attribution Mon Tue Wed Thu Fri Total Development Client project · ALPHA-142 6 5.5 6 4 3 24.5 Code review Client project · ALPHA-137 1 1.5 2 1 5.5 Meetings Internal 1 1 1.5 1 1 5.5 Administration No project or work item (optional) 0.5 1 3 4.5 Daily total 8 8 8 8 8 40 Design representation Every cell stores a UTC instant, an IANA time zone and a business date
A design representation of the weekly grid, not a screenshot of the product. It shows the shape of the model: activity is required on every entry, project and work item are not, and the week moves as one unit into approval.

How time gets captured

  • A one-click timer, with one running timer per person per organization.
  • Manual entry by duration, or by start and end.
  • A weekly grid, a daily view, and a per-project rollup.
  • Billable flag, activity category, and a free-text note.

Why the time maths is trustworthy

Every entry stores a UTC instant, the employee's IANA time zone, and the business date, together. That is what makes an overnight shift and a daylight-saving transition ordinary arithmetic rather than a defect discovered in April and October.

Attribution is offered, never demanded

A time entry needs an employee, a work date, a duration, and an activity category. Project and work item are optional, always. Plenty of organizations track time against categories and nothing else, and a product that refuses to record an hour without a ticket number is unusable for them.

Organizations that want stricter attribution can require it: project mandatory, project mandatory for billable time, or a description required when no work item is chosen. The default is permissive and the policy is yours.

Approvals

Approval is a state machine with a permanent decision log, not an informal nod in a chat thread.

The timesheet approval state machine A period moves from draft to submitted to approved to locked. A submitted period can be rejected back to draft, which requires a comment. An approved period can be reopened by an administrator, which is recorded. Draft Submitted Approved Locked rejected (comment required) reopened (administrative, recorded)

Approved data is immutable

Once a period is approved it is not silently editable. A correction is a new, attributable event, so the history explains itself later. Self-approval is refused unconditionally, including for organization owners.

Chasing is the system's job

Missing-timesheet detection is schedule-aware and holiday-aware, and it notifies people in their own local morning rather than the office's. Managers approve a week for their reports in one screen.

Every change is auditable

Who, what, when, before and after, for every entry and every state transition. A rejection requires a comment, because "rejected" with no reason is a message somebody then has to chase in another tool.

Permissions

"Admin or not" is how accounts become over-privileged and how data leaks between teams. LynxSprint is built on a granular permission catalogue with record-level scopes.

Seven record-level scopes

A permission answers what you may do. A scope answers whose records. Own, direct reports, the whole reporting line, groups you lead, projects you belong to, projects you lead, and the organization.

The org chart is explicit

Reporting manager relationships and group membership are first-class records with effective dates, so approvals route to the right person instead of the person someone remembered to configure.

Multi-organization people are first-class

A person is one identity. Their employment in each organization is a separate profile with its own roles, state and data, so contractors and fractional staff do not need duplicate accounts.

Record-level scopes, narrowest first
  1. Own records yourself
  2. Direct reports people who report to you
  3. Reporting line the whole tree beneath you
  4. Led groups groups you lead
  5. Member projects projects you belong to
  6. Led projects projects you lead
  7. Organization everyone, by explicit grant

Isolation is treated as a safety property

Tenant isolation runs in four independent layers rather than one, and the outcome is simple to state: a request for another organization's data is indistinguishable from a request for data that does not exist. The security page covers what those layers guarantee.

Work and projects

Enough structure to plan and attribute work, and no more. The bounds below are deliberate, and naming them is more useful than implying a depth that is not there. Everything in the first list is in the product today.

What is included

  • Your own vocabulary: types, statuses and priorities you define and reorder. Retiring one archives it, so old items and reports keep resolving.
  • Custom fields in 13 types, including employee, group and version, stored in typed columns rather than a JSON bag.
  • A generated project-scoped key, never reused.
  • Sub-items, links between items, and boards with sprints and a backlog.
  • Comments, mentions, watchers, stars, votes, reactions and attachments.
  • Saved searches, distribution and timeline reports, and a knowledge Library.

What is not

  • Workflow screens, conditions or post-functions. Which status moves a type allows, and what must be filled in first, are yours to set.
  • A second way to tag. Labels are a typed field anybody can add to, not an untyped list beside the fields.
  • Service-desk queues, SLAs and a customer portal.
  • Invoice PDFs, tax lines and credit notes. Rate cards, budgets and invoicing are built; a rendered document and a tax model are not.
  • Email notification for work items. Mentions and digests arrive in the app.

Some of these are on the roadmap, which says which ones and why they are not first.

Projects stay minimal on purpose

A project has a code, a name, a status, a billable flag, a client name, dates, and members. Members exist because project membership is one of the record-level scopes. Budgets, rate cards and milestones wait for a pricing model decision we have not made yet.

See it on your own data

Tell us how your team runs today and we will come back with timings.
Request early access See pricing