Once you have connected your Jira account, you can attach any time entry to a Jira issue right from the entry form. Linking keeps your Time Trakkr hours and your Jira issues in step, and on opted-in projects it pushes those hours back to Jira as worklogs. Connecting Jira is covered in the Jira integration article; this page is about using the link once it is set up.
The Jira field only appears when your own Jira connection is active.
To change your mind, select Unlink next to the badge and search again.
Picking an issue does two helpful things when the entry is still blank:
The inference follows a clear order. First it checks the organization's mapping rules, which an admin maintains and which always win. If no rule applies, it falls back to where entries on that same issue prefix have landed before, preferring your own history. Failing that, it compares the issue's own project and type name against your projects and tasks. If it still cannot tell, it leaves the picker alone for you to choose.
If a rule points at a project that has since been archived or deleted, the picker says the mapping needs attention rather than quietly guessing something else — that way the broken rule gets fixed instead of being worked around.
Admins say where a Jira issue's time belongs using rules, on the Integrations page in the Jira mapping rules card under Organization integrations. The Jira (workspace) card beside it is a separate read-only connection that supplies the Jira project and issue-type lists; rules stay visible and editable without it.
There are three kinds of rule:
customfield_10042 is "Platform". Leave the Jira project blank and it applies across every project, which is what you want for a field like Team or Cost Centre.To add one:
The most specific rule always wins, regardless of the order you added them: a custom-field rule beats an issue-type rule, which beats a whole-project rule. A custom-field rule describes one issue; a project rule describes thousands, so letting the general one win would make the specific one impossible to express at all.
The number on each rule — shown as #300 in the list, and set with Order among … rules when you add one — breaks ties between rules of the same kind only, lower first. It cannot promote a rule over a more specific kind: a whole-project rule set to #1 still loses to an issue-type rule set to #900. Defaults are 100 for custom field, 200 for issue type, 300 for whole project, spaced so you can insert between them without renumbering everything.
Leaving Log time to as Ask every time is a real choice rather than a blank one. That rule still wins, and the picker asks — which is what you want when the answer genuinely varies and you would rather be asked than have a vaguer rule answer confidently and wrongly.
Naming a task is optional. When a rule names one, it is used; when it does not, the picker offers whatever that person last used on the project.
Type an issue key into Check an issue and Time Trakkr shows which rule wins, which rules also matched and lost, and the project and task the time would land on. Use it whenever you add a rule: getting the precedence wrong is silent — the hours simply go to the wrong project and look exactly like somebody picking the wrong one by hand.
If your Jira connection cannot read the issue, the check says so and only whole-project rules are evaluated. That is a different answer from "no rule matched", and it is reported differently on purpose.
Select Remove. Existing entries are not moved; the rule stops applying to issues linked from then on. Adding the same rule back later restores it.
Mirroring hours to Jira is on by default for new projects, and a manager or admin can turn it off per project. It lives on a project's edit page: Push linked entries to Jira as worklogs (for members with a connected Jira account).
Projects created before this changed keep whatever they were set to — turning it on for an existing project is a deliberate choice, because it starts writing worklogs into your Jira for every linked entry from then on.
Nothing happens on a project with no linked entries: an entry with no Jira issue is never considered for syncing, so a workspace that does not use Jira sees nothing at all.
With that on, saving a linked entry adds or updates a matching worklog on the Jira issue, and deleting the entry removes the worklog. Each worklog posts through the member's own Jira connection and is attributed to that member, so people only ever write worklogs they could write in Jira directly. If someone has no Jira connection, their entries simply skip the push; nothing blocks the timesheet.
Sending happens in the background, so saving a timesheet never waits on Jira.
Each entry headed for Jira shows its status on the timesheet. Hover it for the reason in Jira's own words.
| Status | What it means | What to do |
|---|---|---|
| In Jira | The worklog is on the issue. | Nothing. |
| Sending to Jira | Queued. Usually a few seconds. | Wait. |
| Not in Jira | Jira refused the worklog — most often a missing Work On Issues permission, or the issue has hit its worklog limit. | Fix the cause, then select Retry. |
| Changed in Jira | Somebody edited the worklog in Jira after we wrote it, so we stopped rather than overwrite them. | Open the issue and decide which version is right. |
| Jira not connected | That person's Jira connection has expired. | They reconnect on Integrations; entries sync on their own afterwards. |
| Not sent to Jira | Syncing was deliberately skipped — the project has push turned off, or the entry is locked. | Nothing. |
Entries that were never going to Jira show nothing at all, so the status only appears where it means something.
Retry appears on Not in Jira and nowhere else, on purpose.
Changed in Jira has no Retry because re-sending would push our version over the change somebody made in Jira — the exact overwrite we stopped to avoid. One click would discard their correction with no warning. Editing the entry here syncs it again, deliberately.
Jira not connected has no Retry because nothing about the entry is wrong and retrying would fail in exactly the same way. Reconnecting is the fix, and only that person can do it — so the Connect Jira link appears on your own timesheet, never on a colleague's, where it would only connect your account and change nothing.
A manager can retry a teammate's failed entry from that teammate's timesheet. The worklog is still written through the teammate's own Jira connection and attributed to them, so a retry can never log work in Jira as the wrong person.
You can also ask the assistant: "did anything fail to reach Jira this week?"
When your Jira is connected, your week's timesheet shows a small coverage note, for example "Jira: 3 of 8 entries linked this week." If some entries are still unlinked, it nudges you to link issues from the entry form. It is only a prompt; linking is always optional.
Updated 2026-09-09. Still stuck? Contact support or return to the Help Center.