Documentation for JIRA 6.3 EAP developer (EAP) releases only. Not using this? See below:
(JIRA 6.2.x documentation | JIRA OnDemand documentation | earlier versions of JIRA)

Skip to end of metadata
Go to start of metadata

A JIRA workflow is the set of statuses and transitions that an issue goes through during its lifecycle.

Workflows typically represent business processes.

JIRA ships with a built-in workflow called jira, which is the default system workflow and cannot be edited. However, you can make copies of this workflow to get started creating your own workflows quickly. You can also create your own workflows from scratch, or import them from Atlassian Marketplace, if you prefer. Each workflow you create can be associated with particular projects and, optionally, specific issue type(s) by using a workflow scheme.

 

JIRA's default system workflow

On this page:

See also:

What is a status?

A status represents the state of an issue at a particular point in a specific workflow. An issue can be in only one status at a given point in time.

When defining a status, you can optionally specify properties.

What is a transition?

A transition is a link between two statuses that enables an issue to move from one status to another. In order for an issue to move between two statuses, a transition must exist.

A transition is a one-way link, so if an issue needs to move back and forth between two statuses, two transitions need to be created. The available workflow transitions for an issue are listed on the View issue screen, shown here.

Editing a workflow

Editing a workflow means that you are modifying the statuses and transitions that make up a workflow. There are slight differences between editing an inactive and an active workflow, described below. We place restrictions on the modifications you can make to an active workflow, due to the impact the changes will have on projects and/or issue types that use this workflow.

Active versus inactive workflows

An inactive workflow is a workflow that is not currently being used by any projects. Because there are no issues currently transitioning through an inactive workflow, you can simply edit the workflow's steps and transitions. For details on this, see Working in text mode.

An active workflow is a workflow that is currently being used by one or more projects.

When you edit an active workflow, JIRA first creates a draft of it, as shown here.

You can then modify the draft as you see fit. Once you have finished modifying your draft workflow, you can publish your draft and, optionally, save your original workflow as an inactive backup.

Limitations when editing an active workflow

Please note that the following limitations apply when editing an active workflow (i.e. a draft workflow):

  • It is not possible to edit the workflow name (only the description) if a workflow is active.
  • Workflow statuses cannot be deleted.
  • If a status has no outgoing transitions (Global transitions are not considered), it cannot have any new outgoing transitions added, regular or global. 
  • The step ID cannot be changed. See the following article for details on this: Cannot Add Transitions or Delete Steps in Draft Workflows.

If you wish to make any of the modifications listed above, then you will need to copy the workflow (see Creating a workflow), modify the copy and then activate it. 

Workflow designer

Workflow designer, also referred to as Diagram edit mode, allows you to visualize the entire layout of your workflow as well as create and edit a workflow's steps and transitions. 

The JIRA workflow designer looks like this:

Statuses in the workflow designer

There are a number of different actions you can perform with statuses in the workflow designer. You can add a status via the toolbar at the top of the workflow designer. Also, if you select a status, extra information and actions become available in the Properties panel that displays on the right-hand side of the screen.

  • Add status – click the Add status button in the toolbar. You will be able to choose from a list of existing statuses or enter a new status.
  • Remove a status – via Properties panel. Removes the status from the workflow, but not the JIRA instance.
  • Move the status on the screen – click and drag the status to reposition it in the diagram. Geometric snap lines appear to help you align the status with other statuses in the workflow.
  • Edit properties – via Properties panel. properties are advanced configurations on a workflow. Please see Workflow properties for details.
  • Add a global transition – via Properties panel (Allow all status to transition to this one). Global transitions are transitions that allow every other status in the workflow to transition to the selected status.


Diagram showing a selected status, and the operations that can be performed on statuses

(info) Note: Statuses are global objects in JIRA. Changing the name of a status on one workflow also changes the name of the status on all workflows that use that status.

Transitions in the workflow designer

There are a number of different actions you can perform with transitions in the workflow designer. When you select a transition, additional information and actions become available in the Properties panel on the right-hand side of the screen, where you can:

  • Add a transition – click the Add transition button in the toolbar or dragging a port of any status to a port of another status (see the illustration on the right) creates a new transition between the two statuses. You can create a new transition or reuse an existing one (provided that the existing transition has the same destination status).
  • Reposition a transition – selecting a transition highlights the two endpoints of the transition with black dots. Clicking and dragging either of those dots gives you the ability to reposition a transition around its given status.
  • Delete a transition – click the Delete transition button or just use the delete key on your keyboard.
  • Edit a transition – lets you change the name and description. You can also change the screen that the transition uses, see  Working in text mode for details.
  • Configure advanced options – such as properties, post functions, conditions and validators. Please see the Advanced transition configuration  section below.

Diagram showing a selected transition and the operations that can be performed on transitions

Workflow designer tips

  • Hover over a transition or a status to see the relevant transition labels. 
  • When dragging a status on the page, the red lines that display are geometric snap lines that can be used snap to other statuses.
  • Zoom the diagram with your mouse wheel. Pan the diagram by clicking and holding the mouse while on white space, then moving your mouse across the diagram.
  • On the View Issue page, all statuses except the current one are displayed with the white background and blue text. The current status displays a blue background with white text to give it more prominence.
  • When increasing the zoom in a workflow, not the entire workflow will be visible, and a scroll bar won't be displayed. You can click on the white background and drag the workflow up and down, and to the right and left, to better visualize the parts of the workflow that are not visible.

Advanced transition configuration

When defining a transition, you can optionally specify:

  • A screen to be displayed to the user — this is useful if you need the user to provide input before completing the transition.
  • Conditions — these control who can perform a transition (i.e. who can see the transition link on the View issue page).
  • Validators — these check that any user-supplied input is valid before performing the transition. 
  • Post functions — these perform particular actions, such as:
    • Assign the issue to a particular user.
    • Send an email notification.
    • Update a field in the issue.

For more information on working with conditions, validators, and post functions, see Advanced workflow configuration.


Advanced configuration for a transition (conditions, validators, post functions)

Notes

  • You cannot clone transitions in the workflow designer.
  • You cannot create annotations in the workflow designer.
  • You cannot directly set the issue.editable property. To do this, simply add the issue.editable property to the status properties.

Configuring a workflow

Creating a workflow from an existing workflow

  1. Log in as a user with the JIRA Administrators global permission.
  2. Choose > Issues. Select Workflows to open the Workflows page, which displays all of the workflows in your system.
  3. Copy an existing workflow using the Copy link in the Operations column (shown above).
    1. Enter a name and description for your workflow.
    2. Click the Copy button. The workflow opens in edit mode.
  4. Once you have created your new workflow, you may customize it by adding and/or editing steps and transitions.

When you have finished customizing your workflow, see Activating workflow for details on how to use it with a JIRA project.

Creating a workflow from scratch

(info) For advanced administrators

  1. Follow Steps 1 and 2 as described above (in "Creating a workflow from an existing workflow").
  2. At Step 3, click the Add Workflow button instead of copying an existing workflow.
  3. Enter a name and description for your workflow. Click the Add button.
    The workflow opens in edit mode and contains a step called Open. If you are viewing your workflow in Diagram mode, you see an incoming transition called Create.
  4. Continue with your workflow customizations, by adding and editing steps and transitions.

Importing a workflow

Please see the documentation on Importing from Atlassian Marketplace.

Setting the Resolution field

Within JIRA an issue is determined to be Open or Closed based on the value of its Resolution field — not its Status field.

  • An issue is determined to be Open if its Resolution field has not been set.
  • An issue is determined to be Closed if its Resolution field has a value (e.g. Fixed, Cannot Reproduce).

This is true regardless of the current value of the issue's Status field (Open, In Progress, etc).

Therefore, if you need your workflow to force an issue to be Open or Closed, you will need to set the issue's Resolution field during a transition. There are two ways to do this:

Renaming workflow transition buttons

If you copied the system workflow and you wish to rename the workflow transition buttons on the View issue page, you must delete the following properties from all transitions in the copied workflow:

  • jira.i18n.title
  • jira.i18n.description

Otherwise, the default names (i.e. values of these properties) will persist. Read more about transition properties.

Editing a project's workflow for the first time

Whenever a new JIRA project is created, your project automatically uses the default workflow scheme, which associates all available issue types in the project with the JIRA system workflow. Since neither the JIRA system workflow nor the default workflow scheme are editable, JIRA creates an editable copy of the system workflow and workflow scheme for your project.

To begin editing your project's workflow for the first time:

  1. Log in as a user with the JIRA Administrators global permission.
  2. Choose > Projects.
  3. On the Project Administration page, select Workflows.
  4. In the displayed workflow, click the Edit icon at the top-right of the box (shown here):
    A message is displayed letting you know that you are editing your workflow for the first time. Click Continue to proceed.
  5. JIRA automatically does the following:
    • Creates a copy of the system workflow named Your Project Name Workflow.
    • Creates a new workflow scheme for Your Project Name Workflow named Your Project Name Workflow Scheme.
    • Associates any existing issues in your project with the new Your Project Name Workflow.

You can now edit your draft workflow. When you are finished, you are presented with a dialog where you can publish your draft and, optionally, save your original workflow as an inactive backup.

Usage notes:

  • If you have only a small number of existing issues in your JIRA project, this process is relatively quick.
  • If you have many (e.g. thousands of) existing issues in your JIRA project, this process may take some time. 
  • Once this process begins, it cannot be paused or cancelled . Please avoid editing or transitioning any issues within your project while this process is taking place.

Working in text mode

Text mode is an advanced way of working with workflows, and it shows the difference between steps and statuses. In text mode, you work directly with steps. For details, see Working in text mode.

Advanced workflow transitions

For more information on workflow transitions, including built-in JIRA conditions, combining conditions into groups, applying validators and post functions, see Advanced workflow configuration.

120 Comments

  1. Hi Markus, Alexander,

    Have a look on Minyaa Workflow, it allows you to define Common and also Global Transition, and more.

    Vincent

  2. Anonymous

    Hi,

    Is there a way for Jira to configure such that a ticket created in Jira can only be rejected by

    either Reporter or a peer-reviewer (limiting to two or more users without adding them to a group)

    Let me know - Thanks

    1. Anonymous

      This is continuation of above post - Actually there are two new steps added - Peer-Review and Peer-Review-accepted - I would like to know if it is possible in Jira to allow only either the reporter or the assigned Peer to reject the ticket rather than

      every one in the team having permissions to reject it?

  3. Anonymous

    Is there a way to move a JIRA ticket back to the previous status?  Our QA guy moved it ahead by accident.

    1. Sorry, I do not think you can, cause moving to a previous status must be already made in the workflow.

      if something like that happened, we close the issue then reopen it again till we get to the same previous status. for sure , everyone involved must know because of the notifications.

      1. Just to add to what Ahmed mentioned, if you're using JIRA's default workflow (which is bundled with JIRA and is shown in the diagram at the top of this page), you can only proceed to another workflow status/step via the transition arrows shown in that diagram. Also, be aware that you can reopen a ticket from the 'resolved' (as well as the 'closed') status/step.

        If you want to provide users with the ability to move back to a previous status/step, I'd suggest creating a new workflow (either by copying the default one or creating a new one from scratch - as described above) and then add transitions from the relevant steps to the previous steps you'd like your users to move back to.

        Give these transitions appropriate names too - for example, from Closed to Resolved or Resolved to Open, you might use the transition name of 'Go Back'.

        Cheers

  4. Anonymous

    How can I use existing  progresses like| Reopen Issue (3) ? I just want to reuse them again and again. I created a new progress and want to use the existing ones, but how? Is it only possible to create a new progress?

    Thanks, Paul

    1. Hi Paul,

      JIRA Workflow Engine can support Global and Common Transitions. You can define them using XML or using Minyaa Workflow, that provides capacities to define them and also a Graphical Designer.

      Have a look on the post.

      Vincent

    2. You don't need a plugin for that. The Minyaa guys are really agressive... All you need is to use the classic (flash-based) workflow editor built into Jira. It supports global and common transitions.

  5. Anonymous

    Hello,

    I'd like to set the value of a Custom Field using the post-function feature of a transition.  How can i make my custom field appear as an update field option?

    Thanks.

    --jon

    1. I would too but it looks like this is not available yet? 

      https://jira.atlassian.com/browse/JRA-7657

  6. Anonymous

    Is it possible to asign steps of workflow to user. For example if I user1 say that isue is resolved, it will automaticly be assigned to user2? 

    1. yes you can by using the validators example: Field has single value Validator to be User1 as  assignee, and to automatically assign to user2 , Add Post Function To Transition from post  function select : and use the user2 as a name in custom field and then Get Assignee From Custom Field to select this user.

      i hope this works

  7. Anonymous

    I have currently a workflow which ends in the step CLOSED. Now I would like to add a transition REOPEN to the destination step OPEN. However, I don't have the Add Transition function available at the CLOSED step. How can I add this transition ?

    Thanks, René

    1. Hey Rene, if you look at the documentation above, you'll see that you cannot add an outgoing transition from a step that has no existing transitions.

      You must copy the existing workflow, make your change, and activate it in the project

  8. Anonymous

    Hi, Can any one tell me the scop of Jira actually I am new in jira and having more than 5 year exp in java/j2ee it is good for me to work on that tool . or move in my experties area java/j2ee it will be g8 help please suggest guys .

  9. Anonymous

    Is there any way to show a visual representation of the current workflow for an issue (and where where it currently stands in the context of the workflow) to the user? This would be beneficial to a user that might not have sufficient experience with the current workflow and would need to have a reference on the previous/next steps. Thank you. -Ashley

    1. Yes, when you are in an issue, you can click on the View Workflow (if that permission has been granted) and you can see the workflow and specifically which step you are on.

      There are a few challenges:

      You can't really control the display of the flow, and the more steps and transitions you have, the more difficult it is to actually 'see' the workflow.  The workflow designer tool is not very good.  Even if you rearrange your flow in the designer, and change the connector types from straight lines to right angle connectors, it converts them back to straight lines when one views the workflow from an issue.  also, no matter how you arrange the transition labels in the designer, it puts the labels wherever it want to when you view the workflow from an issue.  And the labels are often no where near their respective lines.  And, you cannot turn off the transition labels when viewing the workflow.

  10. Anonymous

    Hi 

    Apologies for my ignorance in advance, I am trying to mimic the permissions in a workflow of one user for another user (who has the same group memberships). Where do I look to find the permissions () that are associated with this workflow so that I can make the same workflow transitions available to his manager

    Thanks in advance

    Carlos

  11. Anonymous

    Hi

    I would like to add a NEW step before OPEN step, but OPEN is the first default step i JIRA. How do I make a NEW step wich will appear at first before OPEN step ?

    Dawid

    1. Hi Dawid,

      As indicated in The Initial Transition ('Create' or 'Create Issue') section (within the Applying Post Functions to Transitions section above), the 'OPEN' step (assuming this is your 'initial step') can only have one 'initial transition' (which is the 'create issue' action).

      Whenever you create a new workflow, you automatically get an initial transition and an initial step. The initial step can have other transitions leading into it, but they must originate from other steps pre-existing in (or which you have added to) the workflow.

      Alternatively, you could do the following:

      1. Rename the OPEN step's 'Step Name (id)' to something else (e.g. 'Pre-Open').
      2. Do either of the following to the status currently linked to this step:
        • Rename the step's current linked status (e.g. from 'Open' to 'Pre-Open').
          (info) Bear in mind, statuses are global in JIRA, so this action will affect the linked statuses of other workflows whose steps link to the 'Open' status.
        • Link a different/new status to the step instead (e.g. a newly created status called 'Pre-Open').
      3. Next, add another step to the workflow called 'Open' (linking an appropriately named status to it - e.g. 'Open').
      4. Add a transition from the 'Pre-Open' step to the 'Open' step.

      Hope this information helps.

      Cheers,
      Giles.

      1. I was facing the same problem. Thanks for a solution, however as such changes indeed affect statuses in all the workflows, it is not an option in my case=(

        Would like to see the feature to modify the initial step/status for a single workflow.

        Regards,

        Anna.

        1. Hi Anna,

          If you used the 2nd option of Step 2 in my response to Dawid above (i.e. 'Link a different/new status to the step instead (e.g. a newly created status called 'Pre-Open')'), would that not provide you with a unique initial step/status for a single workflow?

          Bear in mind, I suspect you'd need to create a new 'global' status for each workflow with a unique initial step/status.

          Cheers,

          Giles.

          1. Hi Giles,

            I can create a new "first" step and link it with status "Open", but when the ticket is created it is automatically moved to status "Open". Or did you mean something else?

            What I did is created a one more "post-open" status "Ready to Start" for my workflow. So "Open" ticket means "New", and "Ready to Start" means "Open" =) This is a solution for me.

            Thanks for your reply,

            Regards,

            Anna.

             

             

  12. Anonymous

    Hi

    Does anyone know if it is possible to use post functions to make transitions for a case after a certain time? Let's say I have a case that automatically should go to state "pending" if it hasn't been assigned after 10 calendar days.

    BR, /Magnus

    1. Hi Magnus,

      Have a look on Auto-Transition Management and the Activity and Unactivity Condition provided by Minyaa.

      Enhancement will come in next release, related to the auto-transitions ...

      Vincent

      1. Anonymous

        Thanks mate :)

  13. Anonymous

    hi,

    could it realize that update the other issue's status at the same time update an issue's status? These two issues are in the different projects, one of them is cloned from the other and moved to different project.

  14. Atlassian,

    Several references are made to using XML to create common transitions or to modify a workflow - but I do not see any documentation or examples of HOW to edit the XML to accomplish this.  Can this be added?

  15. Where's the "Publish" button on the Workflow designer GUI version: v4.4.1#660-r161644?

    When I add a new workflow, it is automatically set to INACTIVE, there is no DRAFT but I can't assign these INACTIVE workflows to a Project.  What am I
    doing wrong.  (wink)

    1. Hi Brent,

      The 'Publish' button is only present when you are editing a 'draft workflow' (which you need to create from an 'active workflow'). An active workflow is one which is currently in use by a project (via a workflow scheme).

      Bear in mind that you cannot create a draft workflow from JIRA's default workflow, which is simply called 'jira'. You can only create copies of this workflow, which initially will be inactive.

      Please refer to the Editing an Active Workflow section (above) for details. To assign a workflow to a project, please refer to Activating workflow.

      Hope this info helps.

      Cheers,

      Giles.

    2. Anonymous

      I believe you need to add/build a workflow SCHEME before addiing to a project.

       

      workflows -->   workflow schemes ---> projects

       

      Apologies if this is already in thread–did not see it.

      1. Indeed that's correct and thanks for the clarification. The Activating workflow page explains how to do this.

        Bear in mind that if you are editing an 'active workflow' — i.e. by creating a draft of an active workflow, there is no need to associate the 'draft workflow' with a workflow scheme, since the 'draft workflow' uses the workflow scheme of the 'active workflow' from which the draft was derived.

        Cheers,

        Giles.

  16. The instructions above say that the four optional post functions must be positioned before the 'Update change history for an issue and store the issue in the database' post function.  Why is this?  What does the "Update change history" post function do, specifically, so that I can understand for other post functions where they need to be relative to that function?

  17. Anonymous

    Hi everyone,

     When I imported a workflow using XML and my process design is completly messed up. Is there any way to keep its design format when you import using XML?

    Regards, Silva

    1. I concur.

      The XML file format contains no concept of placement data so opening the the Workflow diagram results in an auto placement of the status and transitions objects.  And it usually looks like crap.  Even after you spend the effort to rearrange these objects and save the layout, when it is reopen in the design editor or a user views the workflow while viewing an issue, the layout can be changed again.  A nuisance.

  18. Anonymous

    This is an excellent information over here. You have provided very valuable and useful information in this post.

  19. Anonymous

    Hi everyone.  I am using a Listener from the JIRA Toolkit Plugin to transition a ticket from one step to the next when a Reporter/Assignee writes a comment.  How do I now hid the Transition Buttons so that these users do not mistakenly click them?

    Thanks

    Doods

    1. Hi Doods,

      The transition steps are shown depending on the available steps in your workflow. If you do not want the exact steps to be shown for definite roles, you should configure a Condition for this transition - to be available only for exact user roles. It should not conflict with the transition through the listener. Please let me know if it does.

      Regards, 

      Anna.

      1. Thanks for the response Anna.  In our scenario, before applying the JIRA Toolkit Plugin listener, when the Reporter submits a ticket, the status of the ticket is initially "Open".  When an Assignee from our Help Desk team is assigned to the ticket, the status becomes "AO HD Investigating".  When the Assignee clicks the Workflow Transition button "Waiting for Customer", the ticket status becomes "Waiting for Customer".  When the customer clicks the Workflow Transition button "Re-submit", the ticket status returns to "AO HD Investigating".

        Now, with the listener applied, I don't want the Assignee and Reporter clicking any of these Workflow Transition buttons.  All they have to do is write a comment and the status will change accordingly.   They no longer need these buttons.  Therefore, I want these buttons to be hidden from their Workflow menu.  Is this possible?

        Thanks,

        Doods

  20. Hi,

    I already have my workflow ready to go, but it looks like a plate of spaghetti. I want to clean it up, so that people viewing the workflow from the ticket can understand what they are looking at. Is there any way to change from straight lines to Bezier curves for the transitions without recreating the transition? I just want to change how it looks, not accidentally change what it does.

    Thanks,

    Vicki

    1. ok - I worked out how to change to bezier curves and polygonal transitons, but I have found that I need to be able to add more anchor points. Changing from a straight line transition to either, only seems to let me add one anchor point. Any ideas?

      Thanks

      Vicki

      1. Hi Vicki - Did you ever figure out how to do this? I too need more anchor points but I can't figure out how to get them?

        Thanks ~ Pam

        1. Afraid not Pam. I had to recreate every single transition in the workflow and know how many anchors points I would need for the get go (I would just add a whole bunch and then align them if I didn't need them later). Even then I think I came to a point where the designer simply wouldn't allow me to add as many anchor points as I needed for a particular transition. Maybe the designer has been updated since I used it, however.

          1. Thanks Vicki... I never figured it out either! Sounds like a nice enhancement though.

  21. Anonymous

    Hi,

    I have created a new Status field value called "Being Retested" which I included in a Bug issue type workflow, and created the relevant workflow steps for it. But whenever I reach that step in the workflow, the Status appears on the screen as "In Peer Review" (which is the title of the previous step), even though the relevant transitions from "Being Retested" are available as buttons. Is there some kind of screen change I need to make somewhere when using a NEW Status value? I must have overlooked that somehow.

    Thanks for your help!

    Darwin

  22. Hi Markus,

    The Workflow Designer (introduced in JIRA 4.4) is able to create 'common transitions' in addition to 'global transitions' as well.

    The instructions above have been amended to describe how this is done.

    Cheers,

    Giles.

  23. It looks like the graphical Workflow Designer is the only way to change workflows in JIRA 5.0, but it does seem fix the limitations listed at Limitations

    ~Matt

    1. OH, Noooooo!

      My workflows are monsters to work with in the Workflow Designer.  Either I can only see a small part of the workflow or I have to zoom out and expand my browser window and then I can barely read the text.  How can I find something quickly?  In the old workflow editor I could easily search the page for the status or transition I was looking for.  This is bad news...

      Don't get me wrong - I think the new Workflow Designer is cool...  but it certainly has limitations (more than just the ones listed in the link Matt posted).

      1. An XML editor perhaps - ouch!

        1. Hi Matt and Jon,

          You should still be able to access the old View Workflow Steps page to edit your JIRA workflows (in JIRA 5.0).

          To do so, you need to click the hyperlinked number under the Steps column of the View Workflows page. I've updated the instructions above in line with this UI change in JIRA 5.0, but please let me know if there's a problem with the instructions above.

          Cheers,

          Giles.

          1. Giles,

            Sorry I misspoke, and thanks for updating the doc. It certainly isn't obvious that the old editor is still there, but it's good to know.

            BTW, is it true that the limitations listed have gone away with the graphical designer in 5.0? I wasn't able to reproduce them when I tried.s,

            1. Hi Matt,

              That's fine - we're actually looking at addressing that JIRA 5.0 UI change in the next major JIRA version, since some people have had difficulty discovering how to get to the View Workflow Steps page (i.e. the workflow steps editor) in JIRA 5.0.

              Afaia (with a little testing), the limitations you mentioned above still apply when editing a draft of an active workflow in the Workflow Designer. (The Workflow Designer should indicate that you're editing a draft if you are.) However, these limitations don't apply when editing a new (or any inactive) workflow. Hopefully I've now clarified this in the documentation above.

              Cheers,

              Giles.

               

              1. Afaia

                So I was looking all over in this page for user named "Afaia" before I realized it was "As far as I'm aware" (smile)


  24. Anonymous

    Is there a way to create pre-defined subtasks when a new issue is created.  As each subtask is completed, the next subtask is generated and assigned to the appropriate user.  When the last subtask is completed, the status of the parent issue is then changed to Resolved.

    Please let me know if this is possible and some hints on how this can be accomplished.  Thank you in advance!

     

    1. I'd use a post-function in the workflow to create one or more subtasks as they are needed. Or create a template issue and clone it to do them all in one go.

  25. Anonymous

    I tried with the property ops.bar.group.size.opsbar-transitions=0 in the jira-config.properties file but it is not working. Can any one suggest me the way to push the transition buttons under workflow list?

  26.  ops.bar.group.size.opsbar-transitions=1 is working but  ops.bar.group.size.opsbar-transitions=0 is not working. Any suggestions about how to fix this would be greatly appreciated.

  27. Hi guys,

    I need some help here. 

    Scenario: 

    I have 5 columns in my GreenHopper environment (Backlog, In Progress, Done, Integration testing, System Testing) - yes, I know it's a mixture of agile and waterfall =)

    Problem:

    I want to use the burndownn chart, but I need when I transition an issue into the Done column, an event to be triggered, so that the issue on my burndown to be closed, but I can be able to proceed on the flow to the next state (Integration Testing)

     

    How can I achieve that and is it even possible?

     

    10x in advance!

     

    Iv

     

    1. Hi guys,

      A person called Giles Gaskell sent me an answer to the above issue, which was containing the whole workflow configuration page. 10x Giles, but I can make a flow from a scrach, without even copy the default JIRA one. What I can't do is the scenario above, and I really need this, so if you want to help, please read my issue and give me a straight answer.

      I will try to explain my issue once again in more details this time.

      My problem is that I have a workflow containing 5 steps in a row: (Backlog, In Progress, Done, Integration testing, System Testing) and I am using GreenHopper as well.

      After an issue goes into Done in the above workflow, I would like my Burndown chart to indicate this issue as closed, but nevertheless I can still proceed with this issue in the "In Integration Testing" column and so on.

      Please help.

      Thank you in advance!

      Iv

  28. OK.. I got this automated mail again and it is not helpful at all. Come on guys... you can better than this. I am your customer after all (see Certivox accout).

    I'm taking your last too emails as a joke and I don't like it. Really! I told you I'm advanced in JIRA and I need help and you're sending me the manual??? Come on!

    Uuuuuuuuuuuuuusaaaaaaaaaaaaaa and I'm calm now and for a third time I'm asking you for help.

    1. Hi Ivaylo,

      I'm sorry you haven't received a response to your query yet.

      Could I suggest that you post specific use-case queries (like your one above) on the Atlassian Answers site (which you can access from the Get Answers button/link below).

      Many customers who administer and customise JIRA and GreenHopper use Atlassian Answers and you are more likely to get a response to your query faster if you post queries like your one above on that site.

      Kind regards and apologies for not having the time to answer your query.

      Giles.

  29. Anonymous

    veloredHello,

    How to make rules that only group to edit some field & only person view it.

     

  30. Anonymous

    Hi there,

     

    I am trying to edit my workflow and I would like to change the 'In Progress' status to 'In Planning' I can do this on the diagram but when I apply this to a project the 'In Progress' status shown instead. What am I doing wrong?

     

    Thanks

    Lisa

  31. Hi,

     

    For a reason, I need to Add a specific component (lets say "ComponentX") to all of those issues which DONT have any component (by default it would be None).

    I easily search for EMPTY Component Issues (to have Bulk change) and since some of the Issues are already Closed, so I don't have permission to Edit them hence I guess I have to do it through a Workflow.

    Basically this work flow should:

    1- Re-open (if its closed) the issues

    2- Add "ComponentX" as the component

    3- Return them back to their initial status i.e. Close it if it was Close

     

    Can anyone help me to have such Workflow?

    I will appreciate that.

     

    Regards,

    Mas'ood

     

    1. This kind of question is better asked at answers.atlassian.com but the short answer is to use JQL to find the issues and a bulk update to change them. To deal with Closed issues, edit the workflow to remove the jira.editable property that stops the Closed issues being updated.

  32. Anonymous

    The documentation for  opsbar-sequence

    doesn't seem to specify what the significance of the property value is. It just says it determines the order.

    It would be good if it specified the effect a larger number has over a smaller number, etc.

  33. Anonymous

    hello! I want to know! Is it possible to assign one issue to a group of users?

    1. No. You can create a user with an email address of a group though. But then no-one owns the issue and it doesn't get tracked well. I don't recommend it.

  34. Anonymous

    In our organization we create dummy users with an email address associated with a mailing list. That way, the group gets notified and someone can then step-up and assign the issue to themselves. It works quite nicely for us as it provides an "unassigned" state.

    1. Generally I find that separating the concepts of ownership and notification helps keep issues active. Notifications to a mailing list is good. Assignment to a mailing list only works if the team is doing their own triage. If no-one steps up and assigns the issue, it can sit waiting for a long time.

  35. Hi, I want to customize a workflow like this: 

    About drag issue from column A to B, only user1 has this permission. Meanwhile, bout dragging issue back from column B to A, only user2 has this permission.

    Can JIRA/GreenHopper supports this? Thanks for help!

    1. Anonymous

      Topher

       

      By columns, can I assume you are referring to the Rapidboard? You could easily achieve this by creating a transition from workflow status A to status B and use the conditions/validators to restrict this action to user1 (better perhaps to make this assignment through roles rather than directly byindividuals). Then create a transition from status B to status A that is restricted to user2. Then map status A to column A on the rapid board and B to B. This should yield the behavior you are looking for.

      1. Dear,

        Thanks for reply! Case I acted as you said, there's still problem. If I want to edit an active workflow, there are always "Read only" prompt popping up, then the action failed. How to deal with this? Thanks again!

      2. I want to associate the workflow scheme to a Scrum project, but after i've done this, I see that the columns in the scrum board's work mode is still the GreenHopper default one. I can't find how to replace it to my customized one.

  36. Anonymous

     

    Can you rename an active workflow?

    1. Not indeed. 

      I should ask like this: how to transform a workflow between active and inactive status?

  37. Anonymous

    Topher, It should allow you to create a draft workflow (maybe the word draft in the "read only" prompt is clickable?). Once you modify the draft, you should have the option to publish the workflow (which will replace the active one). This means that you can edit a workflow in the background and make sure everything is ok before you push it to live.

    To fix your board, click on the little cog icon on the top right hand corner of the screen. You should see Configuration in the drop down - select this. In the filter tab, you need to select a filter for the tickets you want to display in the board (you may have to set this up first in Issues navigator). Then click on the Columns tab and add/remove/edit the columns you want, then map the workflow states of your new workflow to the columns by dragging them from the left side of the screen into the columns. You can also click on the Swimlanes tab to change what gets displayed in which row. The final tab gives you option to create Quickfilters, which are buttons across the top of your Rapidboard that apply filters across the board (eg. assignee = Topher).

     

    The key thing to realize, is that Rapidboards do not understand workflows - you can build a workflow, but that doesn't impact the board until you map the workflow states to the columns. And even if your workflow is A -> B -> C you can still map them to the columns in the order C -> A -> B if you so wish. The only impact the workflow will have on the board is in which columns you are allowed to drag and drop a ticket.

    Hope this helps

    1. I appreciate your kindly reply!

      But I built the customized workflow in the "JIRA Admin" webpage, your workflow is built in the "GreenHopper->Tools->Configure" webpage.

      I can't add  conditions/validators to the status for restricting user's dragging&dropping operation in your way.

      Any suggestion?

      Thanks!

  38. Anonymous

    Hi Topher,

     

    My workflow is built also in the JIRA admin page. Do you use the workflow designer, or the the "steps" page ( Administration>Issues>Workflows). If you are using the workflow designer, and as long as you are working on a draft copy or inactive workflow, you should be able to hover over the transition label and select the cog shape. This will give you a dropdown for Conditions and Validators, where you can set the permissions for the users. Or if you are clicking on the "steps" to access the table view of the workflow, you should be able to click on the transition link itself. At the bottom of the transition page, you can set conditions and validators. Once you have created permissions for your transitions, once you create your board and add your workflow steps to the column, the tickets will honor the permissions you set in your custom workflow. For example, if you do not have permissions to move a ticket to "in progress", and you have an column in the board that is mapped to only to 'in progress" you will not be allowed to drag a ticket to that column.

     

    Hope this makes more sense.

  39. When I'm creating a workflow from scratch for a ServiceRocket (formerly CustomWare) client, here's what I do. I think this comment could usefully be merged into the workflow documentation somewhere.

    Workflow Design

    • Decide which statuses you need in the workflow. Only add a status if it's useful for reporting. More than a dozen statuses is a complex workflow.
    • Name all the statuses carefully, saying what has happened to the issue (e.g. "Closed", "Development Complete") or what happens next (e.g. "Ready for Test"). Brief names are better than long ones.
    • Create a vertical list of your statuses with the expected, most common set of statuses. This should look like a ladder of statuses.
    • Add a transition arrow from each status to the next status
    • Add a transition arrow from each status to the previous status. This is because people change status by accident sometimes and you want to be able to undo that. You can use a condition so only administrators can see the reverse transition if necessary
    • Name the transitions with their destination status. So a transition entering a status such as "Deployed" would be named "Deploy". Or you can be explicit and name the transition "To Deployed". Brief names are better than long ones. Don't use names that already exist as other actions, e.g. "Assign" or you'll have two buttons with the same name and confuse everyone.
    • Now add the extra statuses that are off the usual path that an issue goes through. Make sure you can return from these statuses to the main path.

    Resolution

    Divide your statuses into two sets: statuses that should not have a resolution set (e.g. Open), and statuses that should have a resolution set (e.g. Closed). Whenever a transition goes from a status in the first set to a status in the second set, the transition should use a transition screen that includes the system Resolution field. When a transition goes from a status in the second set to a status in the first set, the transition should have a post function "Update Issue Field" that sets the Resolution to None. If this isn't done you will see reopened issues that have a resolution and so have a strike-through when their issue key is displayed in JIRA.

    Notifications

    For all transitions change the post function that fires the Generic Event to be something more specific, so that the amount of mail can be minimized. Remember you can create your own custom events to really narrow down JIRA emails.

    Edit Permission

    For each transition add a condition that checks that the current user has Edit permission. This is so that you can make issues read-only using a permission scheme. If this condition isn't present issues can change status even if they can't be edited.

    Transition Screens

    When you click on a transition in an issue it can either just happen or it can pop up a "transition screen". These screens are just like the screens used to decide which fields to show and in what order.  Keep the number of fields on a transition screen to the minimum necessary or the transition becomes an overwhelming set of choices.

    Validators

    Conditions decide whether the transition button is shown. Post functions are run after the transition happens. The third kind of customization is validators, which check the values in the transition screen or issue and can stop the transition from happening. The JIRA Suite Utilities plugin has some useful validators.

    Workflow Properties

    These can be used sparingly to prevent editing of an issue in a certain status such as Closed. The default JIRA workflow does this. They can also be used to restrict which options are seen for the system resolution field. 

    1. This is great information, Matt! I will look at incorporating this into our workflow documentation (as soon as I get out from under the massive load of ADG updates). Cheers!

      1. I've also added it to the third edition of Practical JIRA Administration for JIRA 6

  40. Here's a similar set of guidelines I use when helping clients with GreenHopper.

    GreenHopper cards are JIRA issues, so each issue uses a JIRA workflow. The difference is that GreenHopper lets you assign statuses to columns, e.g. the column "To Do" may have issues in the "Open" and "Reopened" statuses.

    Columns

    Define the names for your columns and which statuses should be mapped to each column. You can have statuses that don't map to any of your columns, and in fact this is sometimes a useful way to not see issues on a board.

    Transitions

    If you want to be able to drag an issue from any column to any other column, you may need to have a transition from every status to every other status. Think of a JIRA workflow as a ladder, but a workflow for use in GreenHopper is more like a fully-connected circle. You'll at least need a transition to one of the statuses in every column. This is an N2 number of transitions. A better approach is to define a common transition for entering each status. That way you only have to define as many as the number of statuses in the workflow.

    Avoid complicated conditions that restrict who can change an issue's status, or you'll have users who are frustrated that they can drag issues to some columns but not other columns.

    Transition Screens

    Many people like to avoid transition screens. When they're dragging issues from one screen to another, they don't want to have pop-ups interrupting them. This is fine except for transitions that need to set a resolution. The resolution can be set in a post function, but which resolution to choose? I recommend choosing the most common resolution, then add another transition between the same two statuses with a transition screen that lets you choose a resolution. When the issue is dragged to the Done column two small areas will appear named after each transition. One could be "Fixed" since it sets the resolution with no pop-up screen, and the other could be named something such as "Close - Other".

    Notifications

    People drag issues around on the work board without realizing that they are sending out email about status changes. You may want to use a custom event for some transitions and have the notification scheme not send out email for that event.

    1. Also, according to GreenHopper Troubleshooting you have to not use the Generic Event in a transition's post function but that's for Classic GreenHopper only I think.

      1. I've also added this information to the third edition of Practical JIRA Administration for JIRA 6

  41. Is there anyway to set admin permissions that allow an admin user to move an issues through a workflow transition without being asigned to it.

     

    case- we have an interactive touch screen board for stand up and we want people to discuss and move issues during stand up chats without having to log in as themselves?

  42. It sounds like the workflows your issues are using have some conditions in them that refer to the user being the assignee. You can create your own workflows or take a copy of the default and modify it to remove this condition. 

    1. Perfect, thank you Matt. I have created and customised workflows but was never aware of conditions.

       

      Do you know if there is a way to skip a step in the workflow if it is a particular issue. for example if i create a bug issue type it should go straight to 'open' and skip 'product WIP'?

  43. Anonymous

    Once has flow schema has been established. Linked status get locked (and cannot be edited)!!!

    Making a copy of the Schema, Disassociating, creating a new project and working on the schema, does not resolve the issue of linked status not being editable... The only solution is starting from scratch?

     

  44. Anonymous

    Thanks for reply Matt,

    I've spent days trying to edit linked status, and started countless projects with new workflow schema.

    I've read the forums, and unable to find an answer on how to enable modification of "locked linked status"

    1. You'll need to edit an inactive workflow. Remove all the transitions from a status and you can delete the status. Re-add the new status.

  45. Anonymous

    can i remove a global transition?

    1. Yes, you can. Just click on it and press the delete transition button. Once you delete it, you will not be able to transition to that status any longer (since it will no longer exist).

  46. Anonymous

    I want to add a transaction to my workflow, where this transaction will be assigned to only specific users. Example

    Issue created, reviewed, and need approved

    To be approved the transaction will be assigned only to people who have authority to approve or reject the Issue. 

    How I can do this.

  47. I've  created new workflow and activated it successfully in new project. But for my status which indicates the completion of my ticket such completion status is not identified. I can suppose it as I don’t receive an e-mail notification about the fact that ticket is closed. When I use GIRA workflow and the same notification scheme I receive an e-mail when status is being changed to “Closed”. How can I display that my status “task is completed” and transfer to i.e. “Complete the task” means  “Close”?

    1. Anonymous

      Hi Tory,

      Are you wanting to send out a notification when you click on "Complete the task"? If so, I believe you should be able to edit the transition and look for "post-function" events. From there you should be able to add a fire a "close" event which will be picked up by the notification scheme and sent out an email. Hope this helps.

      1. Hi Tory,

        The anonymous post above is correct, you can fire events through the listeners which will then be picked up through the notification schemes.

        This would also be a great question to ask on answers.atlassian.com. The community is generally really quick at getting back to you!

        Josh

  48. Thanks to all! my troble is that  I studied JIRA  independently (myself) and my English is not at high level. Please, if it isn't too difficult, show me the link to the detailed instruction. I ask forgiveness for such self-confident request!

  49. O!!!! YES!!!!  I`ve done this! Post - function events is a magic (smile)! THANKS!

  50. If I have generic status that can come from any other status, ex (Pending), I want the next transaction while the status is pending to return to previous status. 

    Example, My current status is (In Review), User choose Pending. now user can back only yo previous status which is In review.

     

     

    1. Anonymous

      I'm not sure if its possible to introduce this kind of logic to the workflow states (at least in the previous version of Jira I couldn't find it - but I haven't tried the latest). A workaround would be to have a series of non-generic pending statuses that would only go back to the previous state. For example, from review, go to Pending Review, or from Design, go to Pending Design.

  51. I have a workflow with Show Transition Labels on, but they do not show in Chrome. They do show in Firefox.

    This is JIRA 6.1.5

    Is this a known issue?

    1. Hi Adolfo, are you still having this problem? I can't reproduce it in JIRA 6.1.5 under Chrome (31.0.1650.63) or Firefox (22) — if it's still not working for you, could you please raise a bug on jira.atlassian.com?

      1. Thanks I will report it.

        In FF it shows all the transition labels.

        In Chrome only when you click on a state. I gues this is not the expected behaviour.

  52. I have a large workflow with 20+ states. When I zoom in and pan, some parts of the workflow are not accesible anymore (like the open state), I have to back and zoom out to see them (small though). Is this the expected behaviour?

    1. Nope, that's not expected behaviour. I've raised JRA-36339 to track this issue, let me know if it's different from the problem you're having. (smile)

      1. Thanks for raising the issue.

  53. Why are the common transitions are gone? They were more than useful. Hope it will be implemented before classic mode dies.

    Case: I'd like to use the same Close transition directing from 6 statuses (so I can configure it easily) rather than having 6 different Close transition. I also don't want to use global transitions as it will be available from every status.

    Sad panda.

    1. It will definitely be implemented before classic mode dies - in fact, we're working on common transitions right now (smile)

      1. Really happy to hear! Meanwhile I continued working with it, and realized, that the new layout editor is definitely a huge step forward. The formerly messed up layouts can be sorted out in a blink of an eye.

        Big like!

  54. Anonymous

    Copying and activating a workflow simply to delete a step is a shit decision. Time to let the business write requirements and then force the dev manager developers who deliver or leave.

  55. When I am editing a draft workflow, why does the workflow editor give me an enabled "Add transition" button, let me fill in the details, and only then tell me that I cannot perform the operation on a draft workflow?  Shouldn't the "Add transition" button be disabled for draft workflows?

    1. Hi Burke, you should be able to add transitions on draft workflows - that's the reason we have drafts, so you can edit your workflow!

      It sounds like a bug to me. Would you mind raising an bug on jira.atlassian.com with some more specific details about what you were trying to do, and what happened?

      Thanks!
      Josh 

  56. New Workflow designer is even  better in 6.2.2! Really happy to reuse transitions - make life easier. One question though: What are the status colors? How can I change them?

    Edit.: Found it at statuses.

  57. I really like the new designer, but where is the copy/clone function? Why has that been removed. It was such a great function when you are working on complex transitions that will be almost the same. Is it gone forever?

    1. Found this:  JRA-37296 - Allow use of cloning of transitions in the new workflow editor Open  and have voted (smile)