Site-wide settings, available to Jira site administrators under Apps → TimeSheets → Settings. This page is a reference: for each setting, what it actually changes, and — where it matters — what it deliberately does not.
Two things to know before changing anything. Some settings are overridden per person (timezone, working weekdays) and some per project (leave auto-decision), so a site value is a default rather than a guarantee. And settings apply going forward: none of them retroactively rewrite entries, approvals or prices that already exist.
1. At a glance
| Setting | Default | Takes effect |
|---|---|---|
| Working hours | 09:00–17:00, 8h/day | Immediately, on capacity displays |
| Working weekdays | Mon–Fri | Immediately, on leave counts and missing days |
| Approval mode | Per entry | Immediately, for new submissions |
| Auto-approve timeout | 72 hours | On the next scheduled sweep |
| Timesheet lock | 30 days | Immediately |
| Leave policies | Half-days on, no negative balance | On the next leave request |
| Leave auto-decision | Off | On the next scheduled sweep |
| Worklog sync | Off | On the next approval |
| Approver delegation | On | Immediately |
| Project overrides | Allowed | Immediately |
| Site timezone | UTC | Only for people with no timezone of their own |
| Reminders | On, 7 days | On the next scheduled run |
| Retention windows | Audit 365 days, everything else forever | On the next sweep |
| Billing | Off | On the next approval |
2. Working hours
A start time, an end time, and hours per day. Of the three, hours per day is the one that does real work.
| Affects | How |
|---|---|
| The daily hours meter | The denominator in 6h / 8h while someone is logging time |
| Capacity in dashboard gadgets | What a full day is worth when showing utilisation |
| Reports | The expected total against which a person's logged time is compared |
What it does not do: it does not stop anybody logging more or fewer hours. The meter is guidance. The only hard daily ceiling is 24 hours, and that is fixed.
Start and end times are presentational — they set expectations on screen and in reminder copy. TimeSheets does not record clock-in and clock-out times, so nothing is validated against them.
3. Working weekdays
Which days of the week count as working days. This one reaches further than most people expect:
| Affects | How |
|---|---|
| Leave day counts | A request spanning a weekend consumes balance only for working days |
| Missing days | A non-working day is never reported as missing |
| Reminders | The nudge for unlogged time skips non-working days |
| Calendar | Non-working days are shown differently |
| Report capacity | The expected hours for a period |
A person's own working weekdays override this. Somebody on a four-day week sets that in their personal settings, and their leave counts and missing days follow their pattern, not the site's. Change the site value and part-time people are unaffected — which is usually what you want, and occasionally a surprise.
4. Approval mode
Per entry or weekly. This changes how everybody works, which is why it is site-wide rather than per project.
| Mode | How time moves |
|---|---|
| Per entry | Each entry is submitted and decided on its own |
| Weekly | Entries are drafts until a whole week is submitted, then decided together |
Switching modes does not convert work already in flight. Entries already pending in per-entry mode stay pending and are still decidable; weeks already submitted stay submitted. Only new work follows the new mode.
See Weekly Submission for what weekly mode changes day to day.
5. Auto-approve timeout
Hours a pending item may sit before a scheduled job approves it. Set it to 0 to switch it off and require a positive decision on everything.
| Affects | How |
|---|---|
| Pending time entries | Approved automatically once older than the timeout |
| Submitted weeks | The weekly sweep uses the same timeout |
| Billing | An auto-approved entry is priced exactly like a manually approved one |
Automatically approved items are recorded as decided by the system, so a reviewer can always distinguish a considered approval from a lapsed one.
This is a convenience, not a control. If your organisation needs every entry positively approved — for a client contract, or an audit — set it to 0 and staff the queue. A timeout is not evidence that anybody looked.
6. Timesheet lock
How many days back people may still edit their own time. 0 disables locking entirely.
| Affects | How |
|---|---|
| Creating entries | Refused on a locked day |
| Editing and deleting | Refused on a locked day |
| Moving an entry | Refused if either the old or new date is locked |
| The Calendar | Locked days are greyed out and their right-click actions disabled |
The window is measured in each person's own timezone, so a lock does not arrive a day early for a colleague further east.
Shortening the window locks more days immediately. Anyone mid-correction will be stopped, so a shorter window is worth announcing. Lengthening it reopens days, which is safe but may be surprising.
Locking can be relieved case by case with an unlock request. It cannot relieve a billed entry — that constraint comes from the invoice, not the calendar.
7. Leave policies
| Policy | Effect when on | Effect when off |
|---|---|---|
| Half-days allowed | People can book 0.5 of a day | The half-day option is not offered |
| Allow negative balance | A request may exceed the remaining balance | A request exceeding the balance is refused |
Negative balances suit organisations that accrue leave through the year and would rather allow a January holiday than block it. Leaving it off suits organisations where the balance is the entitlement.
Turning half-days off does not alter existing half-day leave — history is not rewritten.
8. Leave auto-decision
Settles leave that has been pending too long, in a direction you choose. Three parts: enabled, days, and action (approve or reject). Off by default.
This is the one policy a project can override, if project overrides are allowed. A team whose leave genuinely needs a positive decision can require one while the rest of the site is happy with silence. See Leave Auto-Decision.
Approvers are emailed before a request settles, so the deadline is not a surprise.
9. Worklog sync
Whether approved, issue-linked entries are mirrored into native Jira worklogs. Off by default, because writing to Jira issues is a visible change that ought to be a decision.
| Affects | How |
|---|---|
| Approval | An approved, issue-linked entry writes a Jira worklog |
| Editing an approved entry | The worklog is updated |
| Rejection or deletion | The worklog is removed |
| Entries with no issue | Nothing — they have nowhere to sync, and that is not an error |
Turning it on does not backfill. Previously approved entries are not synced retroactively; only approvals from that point forward write worklogs. Turning it off leaves existing worklogs in place.
If Jira refuses a write, the approval still stands and the error is recorded. Approval never fails because a downstream sync did.
10. Approver delegation
Whether delegation is available at all. On by default.
This exists as an emergency switch: it disables the delegation lookup site-wide without deleting anybody's arrangements. With no delegations set up the feature is already inert, so most sites never touch this.
Switching it off means existing delegates immediately stop being able to act. Their past decisions stand and remain attributed correctly.
11. Project overrides
Whether projects may override site settings at all. On by default.
Turn it off to keep every team on identical rules — useful where consistency matters more than local judgement, or where you have been asked to demonstrate uniform policy. Existing overrides stop being applied while it is off, and start applying again if you turn it back on.
12. Site timezone
The fallback timezone, used only for people who have none of their own.
TimeSheets resolves a person's timezone in this order:
- their personal setting, if they have set one;
- the timezone their last logged entry was recorded in;
- this site setting.
Timezone decides which calendar day an entry belongs to and when the lock window closes for that person. Changing the site value affects only people who have never set one and never logged time.
13. Reminders
Whether the in-app and email nudge for unlogged time runs, and after how many days a gap counts as worth mentioning.
| Setting | Effect |
|---|---|
| Reminders enabled | Master switch for the reminder sweep |
| Threshold days | How far back a missing working day must be before it is flagged |
Missing days are computed from working weekdays, public holidays and approved leave — so a holiday or a booked absence is never nudged about.
14. Data retention windows
How long each category is kept before the retention sweep deletes it. All are in days; 0 means keep forever.
| Window | Default | Note |
|---|---|---|
| Approval history | 365 days | The only one with a non-zero default — this table grows with every decision |
| Leave history | Keep forever | The category with the strongest argument for a shorter window |
| Timesheet history | Keep forever | Entries on an issued invoice are never deleted, whatever this says |
| Email suppressions | Keep forever | Deleting these means the app may email an address that previously bounced |
Deletion is irreversible and there is no restore inside the app. Every window except approval history ships at keep-forever on purpose: an upgrade that quietly started removing people's history would be worse than continuing to hold it while you decide.
The sweep reports what it deleted and what it declined to delete, so a protected row never looks like an empty run. Full detail in Privacy & Data Handling.
15. Billing
Billing is off until you configure it, and configuring it does nothing until a client and a rate exist.
| Setting | Effect |
|---|---|
| Default currency | Suggested when creating a client or a rate. Does not convert anything |
| Increment | Rounds billed time up to a block: none, 6 minutes, 15 minutes or an hour |
| Rounding mode | How a half unit resolves when an amount is rounded |
| Show rates to approvers | Off, and named honestly — an amount reveals the rate behind it |
Increment is the one worth understanding. With none, a client is billed for exactly the time logged. With 15min, a 5-minute entry is billed as 15. The timesheet keeps showing 5 — what was worked and what is charged for are two different numbers, and an invoice line prints the charged one.
Changing the increment does not re-price work already captured. Existing prices keep the increment in force when they were captured; only new approvals use the new setting. Re-price a period explicitly if you want the change applied — see Billing Health.
There is deliberately no currency conversion anywhere in TimeSheets. A rate in a currency other than the client's cannot bill that client, and is reported rather than converted.
16. Scheduler audience
Who recurring reminders reach. There is no *everyone with a licence* option, because Jira does not offer a reliable way to enumerate that — so the roster is derived from sources you choose:
| Source | Covers | Misses |
|---|---|---|
| Past loggers | Anyone who logged time in the lookback window — organic and self-maintaining | Brand-new joiners who have not logged anything yet |
| Jira groups | Everybody in the named groups, including new joiners | People outside those groups |
| Projects | The teams bound to the named projects | People not on a project team |
Sources are combined and de-duplicated. Maximum recipients per run is a hard cost backstop: a run over the cap is truncated and says so, rather than quietly mailing a whole site.
Reminder jobs that fan out to a derived roster also require your own SES account — see Scheduler & Automation.
17. Hub URL
The link emails point back to. TimeSheets derives it automatically; set it explicitly only if your site is reached through a URL the app cannot infer.
Get it wrong and notifications still send — their links just land in the wrong place. Send a test after changing it.
18. Branding and welcome message
A brand colour and the greeting on the Hub. Cosmetic: neither affects permissions, calculations or what anybody can see.
Leaving the colour empty uses the Jira brand token, so the app follows your site's own theme.
19. How settings interact
A few combinations produce behaviour that is not obvious from either setting on its own:
| Combination | What happens |
|---|---|
| Weekly mode + lock window | A week can be locked by the calendar before it is submitted. People must submit inside the window |
| Auto-approve + billing | Time is priced by an unattended job. Prices are dated by the work's date, not the sweep's, so this stays deterministic |
| Lock window + issued invoice | Billed entries are frozen regardless of the window, and an unlock will not reopen them |
| Project overrides off + per-project settings | Existing overrides stop applying but are not deleted, and resume if you turn overrides back on |
| Retention + invoices | The sweep never deletes an entry on an issued invoice, whatever the timesheet window says |
20. What no setting can do
- Let anybody approve their own time or leave.
- Let a delegate act beyond what the person who delegated to them can do.
- Show somebody their own billing rate in their own timesheet.
- Edit an entry that is on an issued invoice, without voiding it first.
- Convert between currencies.
These are properties of the design rather than defaults, which is why they are not on this screen.