How to Block Time Logging on Specific Work Types in Jira Cloud (Using Workflow Properties)

Your organisation uses Tempo Timesheets and needs to prevent users from logging time against certain Jira issue types — like Risk, Assumption, or any work type that exists for tracking purposes only. There’s no toggle for this in Tempo. But there’s a workflow property that does exactly what you need, and it takes five minutes once you know where to look.

Correction, 23 October 2026: an earlier version of this tutorial said the property's value must be empty and that Jira may ignore it if you type true or denied. We tested that on our own test site today and it was wrong. The value made no difference: empty, denied, true and even false all blocked new worklogs. We've also added a section on locking time that's already been logged, since this property alone doesn't stop anyone editing or deleting it.

You have issue types in Jira Cloud that exist purely for tracking — risks, assumptions, dependencies, decisions, whatever your framework calls them. Nobody should be booking hours against them. The work isn’t there. The issue type is a record, not a task. But Tempo Timesheets doesn’t know that, and it happily presents a “Log Time” button on every single issue regardless of type. Users log time against things they shouldn’t, timesheets get polluted, and your project manager starts sending emails asking why someone booked two hours to a risk that hasn’t materialised.

You go looking for a setting in Tempo to restrict time logging per issue type. There isn’t one. Work Attributes are global — you can’t scope them by project or issue type. Tempo Accounts can be closed, but that’s a different axis of control entirely. The feature request for per-project work attribute filtering has been sitting in Tempo’s Ideas Portal since 2019 with 68+ votes and no implementation timeline. The fix isn’t in Tempo. It’s in Jira’s workflow engine.

The Property That Does the Work Jira Cloud workflows support status-level properties — key-value pairs attached to individual statuses that override or restrict permissions while an issue sits in that status. The one you want is:

• Key: jira.permission.work.denied
• Value: (leave empty)

That’s it. When this property exists on a workflow status, Jira takes away the Work on issues permission for any issue currently in that status. The “Log Time” button disappears from both Jira’s native interface and Tempo’s panel on the issue view. No new worklog can be added. Worklogs already on the issue can still be edited, which can add time to them, until you add the properties in the section on time already logged further down.

What to put in the value: Atlassian's examples leave it empty, so do that. But don't lose an hour over it. On 23 October 2026 we set the property on every status of a test workflow with four different values (empty, denied, true and false) and each one refused the next worklog, even for a site admin. As far as we can tell, Jira only checks the key. What does break it is a typo in the key itself, which is the second mistake below.

Step by Step

1. Identify the Right Workflow

Go to Jira Settings → Issues → Workflow Schemes. Find the scheme used by the project(s) containing your target issue type. Check which workflow is mapped to that issue type. If the issue type shares a workflow with other types that should allow time logging, you need to create a separate workflow for the restricted type first. Copy the existing workflow, give it a clear name and update the workflow scheme to map your issue type to the new copy.

This step matters. The property applies to the status, not the issue type. If Risk and Story share a workflow and you add the property to every status, nobody logs time on Stories either. Separate workflows for separate rules.

*2. Add the Property to Every Status *

Open the workflow in the editor. For each status in the workflow:

• Click on the status

• Select Properties

• Add a new property — Key: jira.permission.work.denied with an empty value

• Click Add

Repeat for every status. If you miss one, users can still log time when the issue is in that status. There are no shortcuts here — every status needs the property.

3. Publish the Workflow

Changes to workflows only take effect after publishing. Click Publish and confirm. If Jira asks about saving a backup, that’s fine — save one.

4. Test It

Try to log time on an issue of the restricted work type. For a check that doesn't depend on the UI, send POST /rest/api/3/issue/{issueKey}/worklog with the body {"timeSpentSeconds": 60, "started": "2026-10-23T09:00:00.000+0300"}: you get a 400 whose message starts with your name and says "you do not have the permission to associate a worklog to this issue". We expected a delay here and didn't get one. We made the change through Jira's workflow REST API, which changes the live workflow with no separate publish step, and the next worklog request, about a second later, was refused. So if logging still works for you after publishing, don't just wait: reload the issue, then check that the workflow you edited is the one mapped to the work type (mistake four below).

Common Mistakes That Will Waste Your Time

Worrying about the value. Some answers online tell you to set it to true, Tempo's own help article says denied, and an earlier version of this tutorial said only an empty value works. In our test all three blocked logging, and so did false. Leave it empty because that's what Atlassian's examples show, and spend your checking time on the key.

Including = true in the key name. If you accidentally type jira.permission.work.denied = true as the key (with the equals sign and value as part of the key string), you’ll end up with a nonsense property that does nothing. Check your properties list — you should see one clean entry with the key jira.permission.work.denied and an empty value column. We tried exactly that key on our test workflow and the worklog went straight through.

**Forgetting to publish. **Draft workflow changes are invisible to the system. If you added properties but didn’t publish, nothing happened.

Not checking workflow scheme mapping. You edited a workflow, but is it the one actually mapped to your issue type? Jira Cloud can have multiple workflow schemes, and projects can use different ones. Verify the chain: Project → Workflow Scheme → Workflow → Issue Type mapping.

Applying to a shared workflow. If your target issue type shares a workflow with other types, the property blocks time logging on all types using that workflow. Create a dedicated workflow for the restricted type.

*What About Tempo’s Timesheet View? *

Here’s a nuance worth understanding. The jira.permission.work.denied property is enforced at the Jira platform level. Tempo respects it when rendering the issue view panel — the “Log Time” button disappears. However, if a user tries to log time from Tempo’s main timesheet calendar by searching for the issue, Tempo will either block the submission with a permission error or prevent it from appearing as a loggable target.

With the property in place, Jira's REST API refused each worklog we tried to add with a user's API token, so a user can't get round it that way. Apps that write worklogs under their own account, bulk imports and other integrations are a different matter. We didn't test those, so check them yourself before relying on the property.

Stopping Edits and Deletes on Time Already Logged

jira.permission.work.denied takes away the Work on issues permission, and that only covers new worklogs. The ones already on the issue stay open. With only that property on every status of our test workflow, we could still edit and delete our own existing worklogs, and Jira answered both requests with success.

To freeze those as well, add four more properties to the same statuses, each with an empty value: jira.permission.worklogeditown.denied, jira.permission.worklogdeleteown.denied, jira.permission.worklogeditall.denied and jira.permission.worklogdeleteall.denied. You need the "all" pair even if you only care about people's own time. On our test project the default permission scheme gives Edit All Worklogs and Delete All Worklogs to the Administrators role, and from that role we could still edit and delete our own worklog with only the two "own" properties in place. With all five in place and our account in the Administrators role, Jira refused a new worklog, an edit and a delete. Outside that role, the work.denied property and the two "own" properties were already enough to refuse all three. We only tried this on our own worklogs, so we haven't checked what happens to a colleague's. worklogdeleteown isn't in the permission list on Atlassian's workflow properties page, but Jira honoured it anyway.

Tempo's own article on closed issues uses the same worklogeditown property to stop Tempo users changing their worklogs.

*Applying This Across Multiple Projects *

If the same issue type exists across several projects, each project may use a different workflow scheme and a different workflow. You need to apply the property in every workflow that is mapped to the target issue type across every workflow scheme.

The fastest way to audit this:

• Go to Jira Settings → Issues → Workflow Schemes

• For each scheme, check if your target issue type is present

• Note which workflow is assigned to it

• Add the property to all statuses in that workflow

• Publish

For organisations with many projects, this can be tedious. But it’s a one-time setup. Once the property is on the workflow, every new issue created with that type inherits the restriction automatically.

*The Honest Take *

This is one of those Jira Cloud situations where the answer is simple but the path to finding it isn’t. Tempo doesn’t expose this control because it’s not Tempo’s control to expose — it’s a Jira platform permission. The workflow property system is powerful but poorly surfaced. Most admins don’t think to look at status properties for time tracking restrictions because the UI never hints that they exist.

The property works, and it's been in Jira Cloud for years. The gotchas are the boring ones: a typo in the key, a workflow you didn't publish, a scheme mapping you didn't check, and forgetting that people can still change time they logged before you added it, admins included unless you add the "all" pair as well. Get those right and nobody can add new time to your restricted work types.

You don't need an app or any Tempo configuration. One workflow property on every status stops new worklogs, and four more stopped us editing or deleting our own logged time, from the Administrators role too.

---

Originally published on leanzero.net. More Atlassian, Forge and local-AI write-ups at leanzero.net/blog, and if you're planning a migration or a Forge app, that's what we do: leanzero.net/services.