Card transitions give your team a shortcut for completing common actions in Mingle, such as closing a bug or marking a user story as complete. Card transitions are context sensitive, and are presented to the user only when appropriate to the current state of the card they are working with. Card transitions allow you to define a workflow for your project, you can use transitions to assign work to various team members at different stages of the project lifecycle. Essentially you can use Transitions to automate any set of changes to a card that should be performed in one go.

Card transitions appear as links in the action bar area on cards that match the card properties you specify in the card transition. For example, in the Close defect transition below:

Any card that is of type = bug with a status = fixed will have a link in the action bar called Close defect. Clicking this link will change the card's status to closed and remove the card's previous owner.

You can use transitions to automate common or repetitive tasks, e.g.

When marking a story as ‘Complete’, alongside simply setting the status to completed you might want to gather details like

• Who closed the story
• When it was closed
• What the final amount of effort involved was

This data collection can be automated so that a user only needs a single click to collect and set the values.

You can control changes to property values by marking those properties as transition only. This means that the value of that property can only be set by a transition for regular team members, and cannot be edited directly except by a Project admin. Because you can control when a particular transition will be made available to the user, you can ensure that only specific allowed state transitions can be effected. So for example by making status a transition only field, and specifying that the bug card must have status set to 'fixed' for the Close defect transition - you ensure that bugs can only be closed if they have been fixed.

You would also have to create transitions for the other allowable state changes for the bug status property, examples might include:

• Assign defect - where a defect is 'open' or 'new', which could prompt for a team member, and change the status to 'assigned'
• Reject defect - where a defect is 'open' or 'new', which could prompt for a comment (to collect the reason the defect was rejected) and change the status to 'rejected'
• Reopen defect - which would allow a defect with status = 'closed' to be re-opened, this might prompt for a comment and set the status to 'open'
• Mark defect fixed - where a defect is assigned, which could set the status to 'fixed'

Of course, there are many possible work flows for defect management, but these examples serve to illustrate the sort of state transitions you might want to set up.

It is useful to capture values like Date completed on, or Analysis complete on for reporting purposes, but these values don’t have to be shown on the card and you might choose to ‘Hide’ them. These hidden properties can be updated/captured automatically using transitions

You might want to ensure that only a developer can mark a story as development complete or only a BA can pick up a story for analysis. This can be enforced with the use of transitions. Mark the property as transition only, and then when you create a transition, ensure you have given only appropriate users permission to use the transition.

When a team member is soft deleting a card or removing a story from scope. You can setup transitions to ensure a comment is entered explaining why this action was performed.

Capture values like development effort by prompting for a value when a developer uses the transition “dev complete’. You could also ask a member to set a due date for himself when signing up for a card.

The Card transitions page indicates hidden properties with an orange background.

In some cases you may have hidden card properties which are only used in reporting and do not need to be set directly by users. Setting these hidden properties is a common use for a transition. One common example is to create date properties to track when a card enters specific states. The transitions which change the state of the card set the current date into the corresponding date property at the time the state changes. e.g. "Date Development Started" might get set to (current date) when a developer begins work on a card, then "Date Dev Done" set once it's ready for testing, then "Date Signed Off" set when the card is signed off. If a card property is hidden, this transition link will still display for cards that meet the card property criteria. The user will still be able to see that a hidden property has been updated by a transition if they look at the history for that card.

When you create transitions, you can make them available for all team members or only specific team members. When you select Only selected team members, Mingle displays a list of all team members and you can select the checkbox next to their name to make the transition visible to these people only.

This is useful if you want only certain people performing specific functions. For example, you may decide that only a tester should be able to close defects, so you would make the Close defect transition available only to team members who are testers. To prevent direct access to the properties set in the transition, you should also mark them as transition only. Only Project Administrators can directly update transition only properties.

• Create card transitions
• Modify or Delete card transitions
• Apply transition only properties

• List of common card transitions
• About card properties
• Customizing projects