Documentation for JIRA 6.4 (This documentation includes the project navigation sidebar). Not using this? See below:
(JIRA 6.4 without sidebar documentation | JIRA 6.3.x documentation | JIRA Cloud documentation | earlier versions of JIRA)

Skip to end of metadata
Go to start of metadata

You can use workflow properties to implement restrictions on certain steps or transitions of a workflow (below).

(minus) Please Note: Not everything on this page is recommended!

  • We do not recommend using all of these types of workflow properties as we cannot guarantee that some data and operations (e.g. bulk operations) will not be broken. Hence, use these types of workflow properties at your own risk!

(info) For details on how to implement workflow properties (i.e. step and transition properties) in your workflow, please refer to Configuring Workflow.

Available JIRA workflow properties

There are a few workflow properties which you can use in a transition or step of a workflow. Here are some helpful links:



Related Issues




Resolution id



Add comma-separated resolution ids to the transition properties where you want to not show certain resolutions


Resolution id



Add comma-separated resolution ids to the transition properties


i18n property key



Transition (usage: action submit button name)


i18n property key



Transition (usage: action name, etc.)


true, false


Configuring Workflow



user1, user2 / group1, group2 / role/






Step (usage: only to restrict permission to either roles,group, or users when issue is in that step)



Integer value greater than or equal to 0


Configuring Workflow (Customizing Transitions)

Transitions on the 'View Issue' page

  • No labels


  1. I just tried adding a comment permission restriction to a workflow state in 3.6.5 jira.permission.comment.user  and it works fine. I then tried doing a builk operation to transfer a couple of issues to another workflow state and didn't get any errors. Does anybody know what areas of bulk operations actually break as per the warning above?

    Has anyone else experienced bulk change errors when implementing these permissions?

    1. Hi Ben,

      I have just tested two workflow properties on bulk operation:

      • jira.permission.assignable.user
      • jira.permission.close.user

      And they worked fine. Perhaps this page needs an update.. I'll follow up this anyway.


  2. Where is the list of possible "values" for each of the properties and a description of what they do?

    E.g. Where does it show that you can set jira.issue.editable = false

    I've seen the constant values API documentation but it only shows the permission name but not what possible values it can hold. There is also no description of what each of the properties does?

  3. Your documentation for jira.permission.* give me the following "wrong" information:

    The format is 'jira.permission.[subtasks.]

    Unknown macro: {permission}


    Unknown macro: {type}

    [.suffix]', where:

    is a short name specified in Permissions

    • Unknown macro: {type}
      is a type (group, user, assignee, reporter, lead, userCF) of permission granted, or denied to deny the permission.
    • subtasks., if specified, indicates that the permission applies to the subtasks of issues in this step.

    With "wrong" i mean that

    Unknown macro: {permission}

    is really a short name, but they can not be found in Permissions. For example i looked for the ability to grant the permission to create attachments.

    The correct way is to use jira.permission.attach.user - but following your instruction i tried jira.permission.CREATE_ATTACHMENT.user which won't work. So i had to guess the verb attach  

    1. Hello Tobias,

      You can use the getShortName() method to retrieve the correct short name, actually.

      Yuen-Chi Lian

  4. here it says:

    The format is 'jira.permission.[subtasks.]{permission}.{type}[.suffix]', where:

    But it doesn't say what .suffix is for.

    Update: Ahha, I see in the example the suffix is used, e.g., so I guess it's simply used when you want to specify a value for the same property more than once and the underlying OSWorkflow system requires unique property keys.

    1. That's the intended usage of the suffix parameter. JIRA is expecting each property to be unique, so if you want to use the same property multiple times you have to tack on a suffix to make it unique.

  5. Hi,

    The WorkflowBasedPermissionManager documentation says:

    group, user, assignee, reporter, lead, userCF

    I took a look at the JIRA 3.11 source code and it is also possible to use projectrole where the value is a JIRA project role ID number. E.g.

    Property Key

    Property Value



  6. I've started using the step property functionality, but encountered a problem. I'm using sub-tasks, and in one particular step I would like to restrict the create permission, so that only the assignee could create a sub-task in this particular step. I've got the edit, assign and more or less all other permissions to work, but not the create permission. Probably the problem is that I'm using the wrong short name for create.. I've tried jira.permission.create.assignee for example, but I'm sick of guessing (wink) Anyone, helt please! ;S

  7. I can't find a good list of all possible workflow step and transition properties - I see some references to others not listed above and I know having a complete list will help me come up with better workflows.  Can someone please post a definitive list??

  8. See JRA-6381 for examples of restricting workflow steps using the jira.permission.* property.

  9. I have used jira.permission.assignable.projectrole many times with the role-id as its value.

  10. Anonymous

    Watch out for white spaces!

    Leading or trailing white spaces need to be trimmed in workflow transition properties entry boxes. Currently extra spaces cause enties to be unrecognized.

    "jira.field.resolution.exclude " does not equal "jira.field.resolution.exclude"

  11. vr

    I would restrict possibility of Create issue down to a particular project role.

    How can I do this using transition properties on initial Create workflow transition? thanks

  12. Of all those properties, which ones can break bulk operations and which ones dont?

    1. All except sequence, title and submit could potentially stop a bulk operation working. By far the most common case is with editable though.

      1. The ones I'm most interested in are jira.field.resolution.include and jira.field.resolution.exclude . Would that limit bulk operations in a way an issue could be changed to a resolution the workflow does not allow?

        1. I would expect that they do limit bulk operations but I would test it first to confirm that,

          1. I just tried this out (for excluded) and for bulk transitions, it did the right thing (excluded the ones that ought to be).  I tried then to bulk edit, but the resolution field wasn't even in the list of fields I could edit (anyone know if this is on purpose?)  Either way, the setting seems to "do the right thing" for bulk operations. This is JIRA 4.4.4

            1. I think you need to add resolution to the edit screen in order to be able to bulk edit it. Be careful when doing that though, because it'll force someone to pick a resolution every time they edit a ticket, which can lead to people accidentally entering a resolution when they really just wanted to edit the ticket.

  13. I've just found that for jira.field.resolution.exclude (and I suppose the .include one as well), you can't use the .1, .2, .3 suffix to include multiple values.  I had to use a comma-separated list of resolution ID's for the value.

    that is, this didn't work:

    and this did:

    It's not documented above (or elsewhere that I searched) what valid values are. Very frustrating. I suppose it must be a test (If you can't figure it out, you probably shouldn't be using them?)

    1. I hope it'll remain active, I'm using it and it's valuable.

    2. I totally agree @Mike Curwen.It doesn't work for me too. So here are my questions.

      1. Gerenal Question: where I can find ids for my system resolution, or is it per default if I have 7 resolution, just numbering ids from 1 till 7 ? what if I deleted and added system resoultions, does it change ids?
      2. Can somebody explain how jira.field.resolution.exclude/jira.field.resolution.include option works? It's now clear through description. 
      3. I tried follwing:
        1. Added 7 Resolutions (system resolution: 5 should be displayed for all issue type, rest 2 only for specific workflow )
        2. Added properties to transition via 
          • jira.field.resolution.exclude = 1, 2, 3, 4, 5 => didn't work (only resolution with id 1 was disabled, rest was still there). Even if comment above says that it is complicated, we will have to use exclude, as we have resoultions that shouldn't be displayed for some issue types
          • jira.field.resolution.exclude.1 = 1 -> didn't work at all
          • Question: how to disable five resolutions ?

      If I'm onest I don't understand even the benefit of  jira.field.resolution.include . Because if I will add resolution under Administration>Issue Attributes>Resolution it shows for all issue types. If I use jira.field.resolution.include by adding it to workflow transition, it still doesn't help.

      What I'm doing wrong? How to disable some resolution through workflow properties? Link to description doesn't help. There is no detailed description, only that it "should work" through this properties.


      1. you listed it as 1, 2, 3 (with spaces).  Did you try 1,2,3 (without spaces)? 

        1. Mike Curwen NL yes I tried it jira.field.resolution.exclude = 1,2,3,4,5 doesn't works too. I don't know what I'm doing wrong

          1. Mike,

            Are you using the proper id numbers for your excluded resolution options?

            For example:

            Property Key = jira.field.resolution.exclude and Property Value = 3,8,9,12,13,10000

            where 3, 8, etc. are the id for the exclude resolution options.

  14. @atlassian Resolutions per workflow step is now broken at the top of this page

    1. Hi Matt. I think someone may have already addressed this, but when I click on that link, it takes me here: Resolutions per workflow step

      1. Still broken for me. The link is and it doesn't go anywhere. It's the Reference entry for jira.field.resolution.exclude in the table at the top

        1. Okay, this is really strange. I had a cached version of the page, with the correct link. I cleared my cache, and then saw the behaviour you were seeing. It should be fixed now.

          1. STILL does not work...

  15. You should also link to Advanced Workflow Configuration#Workingwithtransitionproperties and give a good example with screenshot how to actually set a transition property.

  16. Hello there,
    I'm trying to deny comments for a userCF but I don't find the way to.

    • This is ok to forbid any comment to anyone:
      Property : jira.permission.comment                 Value : denied
    • This is ok to forbid any comment to anyone but my-jira-userCF-name:
      Property : jira.permission.comment.userCF    Value : my-jira-userCF-name

    But I would like to do the inverse... deny permission for my-jira-userCF-name value.
    Could someone help ?

    1. Start with the post at

      Does jira.permission.comment.userCF=denied work? Or jira.permission.comment.customfield_12345=denied, or jira.permission.comment.12345=denied. I bet it's something like that.

  17. Hello Matt,
    First,thanks for your answer. J-triks is great but unfortunately it seems JIRA does not provide any functionality to forbid access to a group nor user nor role... just granting an access is possible.
    Here is my feedback :

    • key : jira.permission.comment.userCF  Value : denied
    • Key : jira.permission.comment.customfield_10704  Value : denied
    • Key : jira.permission.comment.customFieldId=10704  Value : denied
    • Key : jira.permission.comment.userCF.denied  Value : customfield_10704
      All these keys do NOT work. They behaves as if the property was : jira.permission.comment = denied
    • Key : jira.permission.comment.userCF  Value : customfield_10704
      This is not what I want to do but the Key is recognized. It allows the user contained in customfield_10704 to comment the issue (forbidding any other user).
      I just wanna do the inverse ^o^
    1. Time to step back. So you have one user who you never want to be able to comment on an issue. Can you use a permission scheme and the Add Comment permission to do this? A group called users-who-can-comment in there, and don't put your one user in that group. Of course that's for all issues in the a project and all states. 

      One problem is that there are many places in JIRA where users can add comments. I know because I tracked them all down for 4.4 so I could use JavaScript to add a button for surpressing email about the comment. The grungiest way to do this would be to recompile a modified validateCreateComment() method in Or even hasPermissionToCreate() in


  18. I am a little confused on where I would put the exclude name at in the workflow transition on how the values work. I am working on JIRA 4 with a quick time frame to move to JIRA 6. However there is no JIRA 4 documentation on how you implement this in the workflow transition properties. The fields are property key and property value. Any help or advice is greatly appreciated.

  19. Anonymous

    I'd like to unassign any tickets that reach Closed state.  I have tried jira.issue.assignee and jira.field.assignee but both are not allowed - any way of doing this?

    1. My advice would be to have this done with the workflow Post Functions in the Edit Issue Field have it change the assignee to unassigned as long as you have that selected in the project for tickets to be unassigned.

      1. Anonymous

        Yes, that was my back up plan (I've checked that looks possible), however I have a large number of transformations to Closed (and Resolved, which I would like to do the same with) and hoped to deal with unassigning in one place.

        Thanks for replies though, Bryan and Geoffrey.

    2. Hello,
      Have you tried to add a postfunction that purges the assignee field on Close transition ?
      Edit : Oups I've just saw Bryan's answer...

  20. Is anyone aware of how to change the default resolution for certain projects? For example I have several projects which use the resolution.exclude. So when a developer goes to resolve a ticket the default is now duplicate. Can I change this for those certain projects?

    1. When you exclude a resolution and it happens to be the default resolution, it appears that the next valid resolution is shown. So I think changing the order of your resolutions in the screen where they are define (up and down arrows) should allow you to choose which resolution is next shown, and so avoid Duplicate. Not sure how I would have a different default resolution for different workflows or projects.

      1. This is exactly what I did after posting my question. Worked like a charm!

  21. Hi,

    I just tried to disabled editable issue on workflow property with key: jira.issue.editable , value: false 

    When issue on this status, Edit button does not visible but inline editable eneable. 

    How can disable inline editting for status? Do you have any idea?

  22. The link "Resolutions per workflow step" points to "" is still broken. Is it ever going to be fixed?

  23. Is it possible to denied a permission to everybody NOT in a group or NOT a reporter?

    I want to restrict edit permission to only reporter at a certain step. and to only certain group in other state.

    jira.permission.edit.(not reporter) = denied

    jira.permission.edit.(not groupname) = denied

    Thank you