JIRA is now available as three separate applications, JIRA Software, JIRA Service Desk, and JIRA Core. For more information on administering these applications, refer to the Administering JIRA Applications documentation.

Workflow properties

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:


To use the following properties, please enter 'name' in 'Property key' field and the values in 'Property value' field.



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 or the next step)


Integer value greater than or equal to 0

Configuring Workflow (Customizing Transitions)

Transitions on the 'View Issue' page

Was this helpful?

Thanks for your feedback!

Why was this unhelpful?

49 Archived comments

  1. User avatar

    Ben Jones

    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?

    05 Oct 2006
    1. User avatar

      YC Lian

      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.


      05 Oct 2006
  2. User avatar

    Ben Jones

    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?

    05 Oct 2006
  3. User avatar

    Tobias Anstett

    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  

    19 Dec 2006
    1. User avatar

      YC Lian

      Hello Tobias,

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

      Yuen-Chi Lian

      20 Dec 2006
  4. User avatar

    Ximon Eighteen

    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. jira.permission.edit.group.2, 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.

    16 Jun 2008
    1. User avatar

      Heath Wolfeld

      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.

      12 Feb 2013
  5. User avatar

    Ximon Eighteen


    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



    30 Jun 2008
  6. User avatar

    Johan Nordholm

    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

    02 Jul 2008
  7. User avatar

    Tyler Theobald

    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??

    20 Jan 2009
  8. User avatar

    Betsy Walker

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

    08 Jul 2010
  9. User avatar

    Darren Martz

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

    29 Sep 2010
  10. User avatar


    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"

    01 Apr 2011
  11. User avatar


    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

    09 Sep 2011
  12. User avatar

    Elvar Bjarki Böðvarsson

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

    02 Mar 2012
    1. User avatar

      Matt Doar (ServiceRocket)

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

      02 Mar 2012
      1. User avatar

        Elvar Bjarki Böðvarsson

        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?

        05 Mar 2012
        1. User avatar

          Matt Doar (ServiceRocket)

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

          05 Mar 2012
          1. User avatar

            Mike Curwen

            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

            18 May 2012
            1. User avatar

              Heath Wolfeld

              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.

              12 Feb 2013
  13. User avatar

    Mike Curwen

    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?)

    18 May 2012
    1. User avatar

      Andreas Gounaris

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

      20 Feb 2013
    1. User avatar

      M. P.

      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 https://confluence.atlassian.com/display/JIRA/Workflow+Properties 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.


      11 Nov 2014
      1. User avatar

        Mike Curwen NL

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

        11 Nov 2014
        1. User avatar

          M. P.

          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

          18 Nov 2014
          1. User avatar

            Jeff Peters


            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.

            29 Jul 2015
  14. User avatar

    Efi Bagourdi

    Mike Curwen thanks... very useful!

    14 Mar 2013
  15. User avatar

    Matt Doar (ServiceRocket)

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

    05 Apr 2013
    1. User avatar

      Susan Griffin [Atlassian]

      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

      06 Jun 2013
      1. User avatar

        Matt Doar (ServiceRocket)

        Still broken for me. The link is https://confluence.atlassian.com/display/JIRA/Workflow+Properties?focusedCommentId=366117619# and it doesn't go anywhere. It's the Reference entry for jira.field.resolution.exclude in the table at the top

        06 Jun 2013
        1. User avatar

          Susan Griffin [Atlassian]

          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.

          07 Jun 2013
          1. User avatar

            soren Nielsen

            STILL does not work...

            02 Jul 2015
  16. User avatar

    Holger Schimanski

    Link to Resolutions per workflow step doesn't work.

    07 Aug 2013
  17. User avatar

    Holger Schimanski

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

    07 Aug 2013
  18. User avatar

    Geoffrey Laparra

    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 ?

    21 Aug 2013
    1. User avatar

      Matt Doar [ServiceRocket]

      Start with the post at http://www.j-tricks.com/1/post/2011/02/permissions-based-on-workflow-status.html

      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.

      22 Aug 2013
  19. User avatar

    Geoffrey Laparra

    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^
    26 Aug 2013
    1. User avatar

      Matt Doar [ServiceRocket]

      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 CommentSystemField.java. Or even hasPermissionToCreate() in DefaultCommentService.java


      31 Aug 2013
  20. User avatar

    Bryan Trummer

    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.

    12 Sep 2013
  21. User avatar


    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?

    07 Jan 2014
    1. User avatar

      Bryan Trummer

      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.

      07 Jan 2014
      1. User avatar


        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.

        08 Jan 2014
    1. User avatar

      Geoffrey Laparra

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

      08 Jan 2014
  22. User avatar

    Bryan Trummer

    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?

    06 May 2014
    1. User avatar

      Matt Doar [ServiceRocket]

      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.

      06 May 2014
      1. User avatar

        Bryan Trummer

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

        06 May 2014
  23. User avatar

    sukran demircali


    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?

    27 Jun 2014
  24. User avatar

    Eunice Mora

    The link "Resolutions per workflow step" points to "https://confluence.atlassian.com/display/JIRA03x/Resolutions+per+workflow+step" is still broken. Is it ever going to be fixed?

    13 Aug 2014
  25. User avatar

    François-Xavier Choinière

    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

    17 Nov 2014
Powered by Confluence and Scroll Viewport