Timesheets & Approval

Overview Back to top

The Timesheets module lets your team submit logged hours for approval and gives managers a clear way to review and approve them. The entire workflow runs inside the WorkHub plugin for Jira.

Here is how the process works at a high level:

1. An admin sets up approval rules that decide who approves whose timesheets.
2. An employee picks a time period, reviews their worklogs, and submits a timesheet.
3. An approver reviews the submission and either approves or rejects it.

Approved timesheets lock the underlying worklogs so they cannot be changed. When both Approval Enabled and Lock on Approval are active in Settings, worklogs are also locked while the timesheet is pending review. Rejected timesheets unlock them so the employee can make corrections and resubmit.

Configuring Approval Rules Back to top

Before anyone can submit a timesheet, an admin must create at least one approval rule. Rules are configured in Settings › Timesheet Access.

Rule types

There are two types of rule, listed from most specific to broadest:

How the system picks an approver

When someone submits a timesheet the system looks for a matching rule in Settings → Timesheet Access. Three rule scopes can match:

1. Per-user rule — a rule for this exact person.
2. Per-team rule — a rule for any team the person belongs to.
3. All-users rule — a catch-all rule covering everyone.

The first matching rule decides the approver. If no rule matches at all, the outcome depends on who the submitter is:

• If the submitter is a regular user — submission is blocked with the error "No timesheet approver is configured for this user. Ask an admin to add an approver rule in Settings → Timesheet Access." Nothing reaches "Pending Approval"; the user simply cannot submit until a rule is added.
• If the submitter is an app admin (or a Jira site administrator) — the timesheet is auto-approved. Admins self-approve in this case because there is no one else to ask. This is the only "fallback" the system has, and it only fires for the admin's own submissions.

Submitting Timesheets Back to top

Employees submit timesheets from the Time Tracking page (not the Timesheets view, which is the review / reporting / approval surface). Select the week to submit on the Time Tracking weekly grid, review your worklogs, and click Submit for Approval.

1. Open Time Tracking and navigate to the week you want to submit. The week end date must not be in the future.
2. Review your worklogs — verify that all worklogs for the week are correct. Once you submit, worklogs in the period are locked from edits (when locking is enabled in the General settings).
3. Click Submit for Approval. The system picks the right approver automatically based on the configured Timesheet Access rules. Your timesheet moves to Pending Approval, where managers can review it from the Timesheets → Approvals section described below.

Timesheet statuses

Every timesheet moves through a set of statuses:

Reviewing & Approving Back to top

If you are an approver you will see pending submissions that require your action. For each submission you can see the employee name, date range, total hours, and number of worklogs.

Pending Approvals

This view shows a list of submitted timesheets waiting for your action. For each submission you can review:

• Employee name and avatar
• Date range and total hours
• Number of worklogs
• Status history showing all past transitions

Taking action

From the pending submissions view you can:

• Click Approve to accept the timesheet and lock the worklogs.
• Click Reject and enter a reason (at least 10 characters) explaining what needs to change. The employee's worklogs are unlocked for correction.

Approval History

The Approval History view lists every approved and rejected timesheet, sorted by review date with the most recent first. Use the user search at the top to narrow the list to a specific employee, and use the Prev/Next controls to page through older entries (20 per page).

Each approved row also exposes a Reopen action so an approver can send the timesheet back for corrections without leaving the history view — see Reopening an approved timesheet below.

Reopening an approved timesheet

If a timesheet was approved but later needs corrections, an approver or admin can reopen it:

1. Find the approved timesheet in Approval History.
2. Click Reopen and enter a reason (at least 1 character) explaining why.
3. The employee's worklogs are unlocked. They can make corrections and resubmit.

Timesheet Layout Back to top

The Timesheets view is organized into five sections in the left sidebar: User Timesheets, Project Timesheets, Custom Timesheets, Progress, and Approvals. Each section contains one or more report modes that slice worklogs and capacity data from different angles.

All views share the same toolbar at the top: a period picker (eight presets — Current/Previous Week, Month, Quarter, Year — or Custom Range), a Day / Week / Month scope picker (timeline views only), navigation arrows and a Today button, two filter pickers (Team / Users and Projects) rendered side-by-side with tag-based selection, and an Export Excel button.

Period Picker

The period picker at the top controls the time range displayed:

• Eight presets in the dropdown: Current Week, Previous Week, Current Month, Previous Month, Current Quarter, Previous Quarter, Current Year, Previous Year.
• Custom Range — pick any start and end date.
• Navigation arrows — move forward or backward by one period of the same length (e.g. month → previous month, custom range → previous range of the same span).
• Today button — jump to the period containing today.

Column Granularity (Day / Week / Month)

Next to the period picker on every timeline view (User Timesheets, Project Timesheets, Custom Timesheets) sits a Day / Week / Month segmented control that changes how worklogs are bucketed into columns. The setting is persisted across reloads and applies globally to all timeline views.

• Day (default) — one column per calendar day with weekday + day-number headers, weekend striping, and the workload heat-map cells you already know.
• Week — one column per Mon–Sun (or Sun–Sat per your locale) week. Hours are summed across the week. The first/last column clip to the period boundary so a partial week renders as partial. Headers are formatted as Mar 16 — 22 (same month), Mar 30 — Apr 5 (cross-month), or Dec 29, 2025 — Jan 4, 2026 (cross-year — weeks that straddle a year boundary stay as a single column with both years tagged on either side).
• Month — one column per calendar month. Header is the month name (year suffix added when the period spans years, e.g. December 2025, January 2026). Edges clip to the period.

User-row heat-map works in every scope. In Day mode each cell tints by the day's logged-vs-available ratio (with distinct shades for leave, holiday, weekend, and conflict). In Week / Month mode the cell tint is computed from the summed available capacity over the column's days vs. the summed logged hours — same five-step palette (low → good → at-capacity → over). Day-level flags (leave / holiday / weekend / conflict) are not surfaced on aggregated cells because a column mixes many days; switch to Day mode to see them. The Excel export carries the same scope-aware tinting.

Cell click drills into the cell — on every row type. Clicking a cell opens the worklog detail dialog filtered to whatever the row represents:

• User row — entries logged by that person.
• Project row — entries on that project, with each entry tagged by contributor.
• Issue row — entries on that issue, contributor-tagged. Issue key becomes the dialog title with the summary as a sub-line.
• Custom Timesheets bucket row — entries that match the bucket path (e.g. Issue Type: Story → Status: In Progress), contributor-tagged. Works at every nesting level.

In Day mode the dialog covers the single clicked date; in Week / Month mode it covers the column's full date range with entries grouped by date, then by issue or allocation within each date. The dialog header shows the column label (e.g. Mar 16 — 22 or Dec 29, 2025 — Jan 4, 2026). For multi-contributor cells (project / issue / custom rows), each entry shows the user's name as a small badge so you can tell at a glance who logged what.

Filters

Use the two filter pickers to narrow data by Team / Users or Projects. Selected filters appear as removable tags beneath the pickers and persist while you switch between views and navigate periods. A Show all button reveals hidden user chips when you have selected many people; Clear all clears every active filter at once.

Cell Colors & Interactions Back to top

In User Timesheets views, each cell on a user row is tinted based on the ratio of logged hours to available capacity. In Day scope this is per-day; in Week / Month scope the ratio uses the column’s aggregated capacity (sum of available hours across the column’s days). The palette matches the Resource Scheduler workload indicator and the Reports, so the visual signal is consistent across the entire plugin.

Clicking a Cell

Cells are clickable on every row type — user, project, issue, and custom-bucket — in every scope (Day, Week, Month). Clicking opens the appropriate detail dialog filtered to whatever the row represents:

• User row, regular day with logged hours — opens the Worklog Detail dialog with every Jira worklog and allocation that user contributed, grouped by issue.
• User row, approved leave day (blue) — opens the Leave Detail dialog with the leave type, date range, full/half day, total days, approver, and optional note. Day scope only — aggregated Week/Month cells don’t carry a single leave status.
• User row, conflict cell (red with hours on a leave day) — opens the Leave Detail dialog and lists every worklog logged on that leave day, so the conflict is visible at a glance. Day scope only.
• Project / Issue / Custom-bucket row — opens the Worklog Detail dialog scoped to that entity. When the cell aggregates work from multiple contributors, each entry shows the user’s name as a small badge so you can tell who logged what at a glance.
• Week / Month scope cells — the dialog opens with the column’s full date range and groups entries by date, then by issue or allocation within each date, so you see the per-day breakdown that produced the aggregated total.
• Empty cells (no logged hours, no leave) — are not clickable.

User Timesheets Back to top

User Timesheets show logged hours grouped by person. Three sub-views provide increasing levels of detail.

Summary

A flat table with one row per person. Each row shows the person's avatar, a progress donut chart with percentage, a total SUM H (hours logged in the period), and daily columns showing hours per day. A Total row at the bottom sums all users.

by Project

An expandable tree grouped as Person → Project. Each person row expands to show which Jira projects (and allocations) they logged time against, with project keys and names. Daily columns show hours per project per day.

By Item

The most detailed user view. Grouped as Person → Issue/Allocation. Each person row expands to list every individual issue (with key and summary) and allocation they logged time against. Shows the worklog description text alongside daily columns.

Project Timesheets Back to top

Project Timesheets flip the hierarchy: data is grouped by project first, then by person or issue. Two sub-views are available.

Summary

A flat table with one row per project (or allocation). Each row shows the project key, icon, and name, with total hours and daily columns. Functions the same as User Timesheets Summary but grouped by project.

By User

An expandable tree grouped as Project/Allocation → Person. Each project row expands to show which team members logged time against it, with their avatars and names. Daily columns show hours per person per day.

Custom Timesheets Back to top

Custom Timesheets is a configurable view in the left sidebar (under Custom Timesheets → Configurable) that lets you group worklogs by any combination of Jira fields — up to 5 nested levels. Pick a field in the Group by dropdown for the top-level grouping, then add additional Then by levels to nest deeper, e.g. Issue Type → Assignee → Status.

Configuring grouping levels

When you first open the view, a single empty Group by picker is shown. As soon as you pick a field, a new placeholder Then by picker appears below for the next level — so adding a hierarchy feels like filling in a form rather than discovering a button. Click the × next to any level to remove it; the levels below shift up. The dashed-bordered picker at the bottom is always the next available level. Once you reach 5 levels the placeholder disappears and a (Maximum 5 levels) hint replaces it.

Each dropdown supports type-to-search filtering: open a picker and start typing to narrow the list by field name or id. Fields are grouped into two sections inside the dropdown: Common fields (Jira built-ins like Priority, Status, Assignee) at the top and Custom fields (everything you have configured in your Jira site) below. Each option shows its type in italic on the right (single-select, multi-user, sprint, …) so you can tell at a glance which buckets to expect. Fields you have already chosen at another level are hidden from the list.

Your level configuration is persisted per browser: switching to another sidebar item or closing the tab and coming back restores the same grouping. If a Jira admin deletes a field you had selected, the picker shows a warning banner (“The previously selected field is no longer available”) and the missing level is automatically pruned from the list once the fields list is reconciled with the persisted selection.

Supported field types

Common fields (built-in): Assignee, Reporter, Creator, Priority, Status, Resolution, Issue Type, Labels, Components, Fix Versions, Versions, Project.

Custom fields: every classifiable type is supported — single-select, multi-select, radio buttons, multi-checkboxes, user picker, multi-user picker, labels, components, fix versions, sprint, group picker, multi-group picker, project picker, text, number, date, datetime, and cascading select. Custom fields whose schema we cannot classify (rare app-specific types) are filtered out so the dropdown does not surface options that would silently bucket as (No value).

Multi-value field totals

When a level groups by a multi-value field (multi-select, labels, sprints, multi-user, components, …), an issue with multiple values appears under each bucket at that level. The top-level total at the bottom of the timeline counts every worklog entry exactly once, regardless of how many buckets it lives in. Per-bucket totals sum every entry placed in that bucket, so for multi-value dimensions the sum of bucket totals can exceed the top total — this matches how most BI tools handle multi-value grouping.

Multiple multi-value levels can compound: with 5 nested levels, each grouping by a multi-value field with three values per issue, a single entry can appear under up to 3⁵ = 243 leaf buckets. The top-level total stays accurate (each entry still counted once), but per-bucket totals at deeper levels can be heavily inflated. If totals look surprising, check whether one of your levels is a multi-value field.

“(No value)” bucket

At each level, worklogs whose Jira issue has no value for the chosen field land in a (No value) bucket. This bucket sorts to the bottom of its parent so real values group at the top. The same fallback also catches worklogs whose issue could not be located in Jira — rare in practice, usually only for very old issues that have been moved or archived.

“Allocations” bucket

Internal allocation worklogs (time logged against a project allocation rather than a Jira issue) land in a dedicated Allocations bucket at the top level, regardless of how many grouping levels you have configured or which fields they use. Jira custom fields don’t apply to allocations, so the Allocations bucket is always flat — it has no children even when deeper levels exist. It sorts between the real custom-field values and the (No value) bucket so you can always see the allocation total at a glance. When no levels are configured at all, the timeline still shows the Allocations row alone (issue worklogs are hidden because there is nothing to group them by).

Actuals only

Custom Timesheets shows logged hours only. Planned-hours columns and the Progress column are hidden because a custom-field bucket (e.g. “Severity = High”) is not a person and has no capacity scheme — comparing logged time against capacity at that level would not be meaningful. To compare planned vs actual, use the dedicated Reports for that purpose.

Progress Back to top

The Progress section contains three capacity-focused views. Each answers a different question about your team's time. All three group users by team with Subtotal rows per team and a Total row at the bottom.

How the numbers are calculated

Every column in the three Progress views is derived from one of four ingredients. Knowing exactly what each ingredient is — and what it deliberately is not — will save you a lot of "why doesn't this match?" debugging.

Planned Hours — the long version

For each Jira issue assigned to the user whose start → end date range overlaps the period, WorkHub takes the issue's Original Estimate and spreads it evenly across the issue's working days (i.e. days that match the user's capacity scheme working days, excluding holidays and approved leave). The portion of that distribution that falls inside the selected period contributes to the user's Planned Hours.

On top of issues, every custom allocation covering the user in the period adds its declared hours per day to Planned Hours, for each working day the allocation overlaps. Allocations are not estimated — they are scheduled flat hours.

A few specifics that often surprise people:

• Original estimate, not remaining. Progress views always use the issue's original estimate. They never use remaining estimate. This is deliberate: as work is logged, Jira automatically decrements the remaining estimate, so a remaining-estimate "Planned" would shrink the more you log — making any Logged-vs-Planned comparison meaningless. By pinning to the original estimate, the planned bar stays fixed and the progress percentage reflects actual delivery against the original commitment.
• Done issues still contribute. A completed issue's original estimate is still distributed across its date range. It does not drop out of Planned Hours after closing — that's exactly the value you want to compare actuals against.
• Issues without an original estimate contribute 0. If an issue has no Original Estimate set on the Jira side, it adds nothing to Planned Hours regardless of how long its date range is. To get a meaningful Planned figure, your team must populate Original Estimate on issues.

Example. An issue with an 80 h Original Estimate is scheduled across two weeks (Mon–Fri × 2 = 10 working days, so 8 h/day). If the user views the timesheet for just one of those weeks, that issue contributes 5 × 8 = 40 h to their Planned Hours — only the portion that falls inside the selected period.

For the Reports gallery (Resource Utilization Forecast and Project Resources), the calculation switches to remaining estimate — those reports answer "how much capacity is still committed?", which is the opposite question. If you compare numbers between a Progress view and a Reports view and they differ, this is the most likely reason.

Timesheet Progress

Question it answers: How much of their required capacity has each person logged?

How to use: Run this at the end of each week to check who hasn't finished logging. If someone's bar is well below 100%, they may have unrecorded work.

Resource Utilization

Question it answers: How does planned work compare to available capacity?

How to use: Use this during sprint planning to check if the workload is balanced. If someone is over 100%, they are overbooked.

Planned vs Actual

Question it answers: How does actual logged time compare to what was planned?

How to use: Run this after a sprint or at month-end to compare estimates versus actuals. If logged hours consistently exceed planned, your team may be underestimating.

Exporting to Excel Back to top

Every timeline view has an Export Excel button in the toolbar. The export produces a spreadsheet that mirrors what you see on screen, so you can share or archive data without losing context.

• Column layout matches the on-screen table: Entity (person, project, issue, or custom-bucket), Progress, Sum (h), and one column per bucket in the selected period — daily in Day scope, weekly in Week scope, monthly in Month scope. The column header text matches the on-screen label (ISO date in Day, e.g. Mar 16 — 22 in Week, March 2026 in Month, with year tags on cross-year columns).
• Progress column is included only when the on-screen view shows it. In Project Timesheets views (project-rollup rows), the Progress column is omitted from the export as well, keeping the sheet clean.
• Cells are color-coded on user rows using the same workload palette as the UI (5 utilization tiers). In Day scope, distinct tints are also applied for leave, holiday, and conflict cells. In Week / Month scope, those day-only tints are dropped because a column aggregates many days — switch to Day mode to see them, same as the UI. Excel fills have no transparency, so the UI’s translucent tint is pre-blended with white to produce a readable solid color.
• Progress values are shown with two decimals (e.g. 85.16%), identical to the on-screen value — no rounding drift between the timeline and the Progress view.
• Totals row at the bottom sums all top-level rows, matching the footer shown on screen.
• Frozen header keeps the column titles visible while scrolling through large periods.
• Hierarchical group rendering — nested rows (User Timesheets by Project, Project Timesheets by User, and especially the multi-level Custom Timesheets) export with two reinforcing visual cues:
  • Each child row’s label is indented in proportion to its depth so the hierarchy reads at a glance even on a printout.
  • Native Excel row outlining is applied: clicking the +/− toggles in the row gutter collapses or expands a group exactly like the in-app expand/collapse. Summary rows are kept above their children (the export sets summaryBelow: false) so the parent always sits at the top of its group.
  The Entity column auto-widens by ~3 characters per level so deeply nested labels are not crowded; the day-cell column width grows to ~22 chars in Week scope so cross-year labels like Dec 29, 2025 — Jan 4, 2026 stay readable.

Related Pages Back to top