Statuses represent stages in a workflow, and the path that takes an issue from one status to the next is known as a transition. A transition links two statuses together. A transition cannot exist on its own, meaning it must have a start and finish status and can only have one of each. This means that a transition cannot conditionally split off to different destination statuses. Transitions are also one-way only. This means that if a transition takes an issue from status A to status B, you must create a new transition if you want to go back from status B to status A.

Transitions have several components. They are as follows:

• Conditions: Criteria must be met before the transition is available (visible) for users to execute. It is usually used to control permissions around how users can execute the transition.
• Validators: These are the verifications that must pass before the transition can be executed. They are usually used together with transition screens.
• Post functions: These are additional functions to be performed as part of the transition process.
• Transition screen: This is an optional screen to be displayed when a user is executing the transition. It is usually used to capture additional information as a part of the transition.
• Triggers: If you have integrated Jira with other development tools such as Bitbucket or GitHub, triggers can automatically execute the transition when an event happens, such as the creation of a new branch or when someone makes a code commit.

Each of the first three components defines the behavior of the transitions, allowing you to perform pre- and post-validations, as well as post-execution processing on the transition execution. We will discuss these components in depth in the following sections.