GettingMoreJiraWorkflows CLD LW 2020-12-03-Lab

Getting More from
Jira Workflows
- Cloud
Lab Workbook
Getting More from Jira Workflows - Cloud Copyright © 2020 Atlassian
Table of Contents
Introduction ........................................................................................................................................................................ i
Lab 1 – Course Overview ........................................................................................................................................... 1
There is no lab for this module. .............................................................................................................. 1
Lab 2 – Covering the Basics................................................................................................................................... 3
Exercise 1 – Exploring Workflow ........................................................................................................... 3
Exercise 2 – Updating a Workflow Scheme................................................................................ 13
Lab 2 Appendix ................................................................................................................................................ 19
Lab 3 – Creating Conditions & Validators ................................................................................................. 21
Scenario ................................................................................................................................................................ 21
Exercise 1 – Adding Conditions............................................................................................................. 21
Exercise 2 – Adding Validators ............................................................................................................ 27
Optional Exercise 3 – Troubleshooting a Workflow Problem ...................................... 32
Lab 3 Appendix ................................................................................................................................................ 41
Lab 4 – Creating Post Functions ..................................................................................................................... 43
Scenario ............................................................................................................................................................... 43
Exercise 1 – Setting the Resolution in Post Functions ....................................................... 43
Exercise 2 – Copying Field Values in Post Functions ..........................................................47
Lab 4 Appendix ................................................................................................................................................ 51
Lab 5 –Triggering Transitions ............................................................................................................................ 53
There is no lab for this module. .......................................................................................................... 53
Lab 5 Appendix ............................................................................................................................................... 53
Lab 6 – Extending Workflows with Properties .................................................................................... 55
Scenario ............................................................................................................................................................... 55
Exercise 1 – Restricting Actions in Statuses .............................................................................. 55
Exercise 2 – Viewing Properties in the Jira Workflow........................................................ 62
Lab 6 Appendix ............................................................................................................................................... 64
Lab 7 –Taking It to the Next Level ................................................................................................................. 67
Scenario ............................................................................................................................................................... 67
Exercise 1 – Adding Approval to a Workflow ............................................................................ 67
Exercise 2 – Adding Rejection to a Workflow ........................................................................... 77
Optional Exercise 3 – Share a Workflow .....................................................................................80
Lab 7 Appendix ............................................................................................................................................... 83

Introduction
Many labs have optional exercises. These are not required to be done to complete
the course. However, if you have time and interest, they supplement the exercises
for the lab.
There are also appendices, which you don’t need during class. They are full of
useful information like additional reading and best practices. Dig into this section
after class!
You'll log in as various users throughout the course. Here's a list of the users and
what role they'll have.
Name Role
Alana Grant Jira administrator
William Smith Project administrator
Jennifer Evans Developer
Harvey Jennings Content Manager
Ryan Lee Site administrator
To log in during the labs you'll need each user's email address and the password.
You should have received this information after registering for the course.
The password for every account you use in these labs is the same. Keep this
password easily accessible.
You should have also received your assigned site URL. Make a note of this.
When switching between products in these labs, you'll be able to see other
sites. It's important that you choose the product on the site that's been
assigned to you.
The language you see in the Atlassian product UI is set to your browser's language.
If you wish to see the UI in English (to match the lab instructions), or in a different
language, go to your Atlassian product user profile and edit your preferences.
Because the Cloud products are constantly being updated with new features, you
may see some slight differences between the instructions in this lab workbook
and the product you are using.
03 December 2020 – Cloud

Lab 1 – Course Overview
There is no lab for this module.
1 Getting More from Jira Workflows - Cloud Copyright © 2020 Atlassian

Lab 2 – Covering the Basics
Scenario
Here you explore the workflow currently in use by the Teams in Space project. You
initially log in as the Teams in Space project admin to see how he can edit the
workflow used for his project. Then you log in as the Jira admin who can fully edit
the workflow. You rename a status in the workflow and then configure the
project’s board to match the updated status.
In the second exercise, you view a simplified workflow. Then you add that
workflow to the Teams in Space workflow scheme so it can be used by certain
issue types.
Exercise 1 – Exploring Workflow

High-Level Instructions
If you would prefer to follow step-by-step instructions, go to Detailed Instructions
on page 7.
1. View the Teams in Space workflow:

a. Go to your site URL and log in as William Smith, the Teams in Space
project admin. Use the email address that corresponds to his name
and the password that you should have received.
It's important you log into the site that's been assigned to you.
Bookmark this address to save you time later when logging in as
other users.
b. If you see a prompt to select navigation, choose Use improved

navigation. This gives you a horizontal menu bar at the top of Jira.
You can also do this at any time by clicking on your avatar and
choosing Try the new navigation.
c. View Teams in Space board on the Active sprints page in the Teams
in Space project.
This is a representation of the project’s workflow and you can see

the issues in different statuses (columns) on the board.

Is the project admin able to edit the workflow?
Answer: No, he isn’t. The workflow in Jira Cloud needs to be changed

by a Jira administrator.
What transitions run between IN PROGRESS and INSPECTION?
Answer: The Ready for review transition runs from IN PROGRESS to

INSPECTION and the Code review failed transition runs from
INSPECTION back to IN PROGRESS.
d. Exit the workflow view.
2. View the project’s board configuration:

a. Configure the Teams in Space project’s board.
What role does the project admin need to configure this board?
Answer: The project admin needs to be a Board administrator. You

can see William Smith is listed in the Administrators list on this page
so he’s all set.
To add more board administrators, simply edit this list here and add
users.
b. View the board’s Columns Page.
Here you see how the workflow statuses map to the board’s
columns. By default, the column names will be the same as the
status names. But the project admin could rename the column
headings if they wished. You may want to do this if the underlying
status name is not very intuitive. We’ll do this a bit later in the
exercise.

He can add columns to the board. Can he add statuses? If not, why
not?
Answer: No, he cannot add statuses to this board because this

board is not using the simplified workflow. You can only add
statuses to the board on this page, if the board is using the
simplified workflow.
c. In these labs you'll log in and out as various users. To lessen the
amount of logging in and out, use different browser windows.
However, you can't just open a new tab and log in as another user,
as your original tab will be logged in as that user too. You have a
few options:
i. Open an incognito/private window in your current browser.
ii. Open a separate browser if you have another one installed.
For example, if you're using Google Chrome, open Firefox.
iii. Log out as the current user by clicking their avatar at the
bottom of the global sidebar. This method will require a lot of
logging in and out!
To simplify the instructions, when you need to log in as another user,
we'll tell you to use your incognito window, but use the method that
works for you.
3. Rename a workflow status:
The company wants to rename one of their statuses, Inspection, to In

Code Review. All their development teams are doing more types of code
review now in this step so the Inspection name has become obsolete.
And they feel the new name will be easier to understand, especially for
non-developers who may view the board.
Be careful when renaming statuses as this will affect any filters created
using the existing status. Ensure everyone is aware of the change.
Ensure your status and transition names are intuitive. People should
never have to wonder what a status means or which workflow
transition to use next.
a. Since only Jira admins can access Jira administration and update
statuses, open a new incognito browser window, go to your site URL
and log in as Alana Grant.
b. On the Jira administration Statuses page, note the Category column.
The categories – To Do, In Progress, and Done – help you identify

where issues are in their lifecycle, particularly in places where a

large number of issues are rolled up e.g. Version Details page and
Sprint Health gadget. The category is also used to map statuses to
columns when creating a new board.
c. View the Inspection status.
What should you do before renaming a status?
Answer: Before renaming a status, always check to see if it’s in use

by another workflow. Statuses can be shared by many workflows. In
this case, there’s only one associated workflow, TIS DEV workflow.
You can check this by clicking the 1 associated workflow link. You
also want to think about whether the original status might want to
be used again in the future. In this case it won’t as they’ve changed
their type of code review. If another workflow is using the status or it
might be used in the future, you’d need to create a new status.
d. Rename the Inspection status to In Code Review with the

description, Issue is in code review.
e. Edit the TIS DEV workflow and confirm the new status name.
f. In text mode, note that the step still uses the old name. Edit and
rename this step also to avoid confusion for future editors of this
workflow.
Note that you’re now editing a draft (inactive) version of this

workflow and not the live workflow. No changes are made to the live
workflow until you publish this draft.
g. Confirm the step name and the linked status name are now the
same.
h. Publish the draft workflow to make it active (saving a backup copy if
you wish).
Each time you publish a draft workflow you’re given the option to
create a backup copy. This is a good idea if you want to save the
original workflow for later re-use or if you’re making a lot of changes
and you may need to roll them back.
4. Configure the project’s board:

a. Return to the Teams in Space board, TIS Scrum.
What needs to be done now?
Answer: You need to rename the column heading to match the

status. Recall that they can be different but for ease of use we’ll

rename both the status and the column.
b. Configure the board and change the Inspection column heading to In

Code Review.
c. Open one of the issues in this column in full page view and note the
IN CODE REVIEW status shown in the issue.
d. View the workflow from the issue and confirm you now see the IN
CODE REVIEW status.
You can disable the View Workflow link in issues by removing users
(ideally by using project roles) from the View Read-Only Workflow
permission in the permission scheme used by the project.
e. Close this workflow window.
To start the next exercise, go to page 13.
Detailed Instructions
1. View the Teams in Space workflow:
a. Go to your site URL and log in as William Smith, the Teams in Space
project admin. Use the email address that corresponds to his name
and the password that you should have received.
It's important you log into the site that's been assigned to you.
Bookmark this address to save you time later when logging in as
other users.
b. If you see a prompt to select navigation, choose Use improved

navigation. This gives you a horizontal menu bar at the top of Jira.
You can also do this at any time by clicking on your avatar and
choosing Try the new navigation.
c. Navigate to the Teams in Space project.
d. On the Active sprints page, view the board.
This is a representation of the project’s workflow and you can see

the issues in different statuses (columns) on the board.

e. Go to the project settings by clicking Project settings in the project
sidebar.
f. Click Workflows in the sidebar. On the Workflows page, you see the
workflow in use by this project, TIS DEV workflow.
From here the project admin can view the workflow as text or
diagram. Click diagram on the Workflows page.
Is the project admin able to edit the workflow?
Answer: No, he isn’t. The workflow in Jira Cloud needs to be changed

by a Jira administrator.
What transitions run between IN PROGRESS and INSPECTION?
Answer: To see the transition names, mouse over lines between the
statuses. You can see that the Ready for review transition runs from
IN PROGRESS to INSPECTION and the Code review failed transition

runs from INSPECTION back to IN PROGRESS.
g. Click Close to exit the workflow view.
2. View the project’s board configuration:

a. Return to the project’s board (Back to project) and select Board
settings from the board menu (3 horizontal dots icon in the top right
corner).
View the General page.
What role does the project admin need to configure this board?
Answer: The project admin needs to be a Board administrator. You

can see William Smith is listed in the Administrators list on this page
so he’s all set.
To add more board administrators, simply edit this list here and add

users.
b. Click Columns in the sidebar.
Here you see how the workflow statuses map to the board’s
columns. By default, the column names will be the same as the
status names. But the project admin could rename the column
headings if they wished. You may want to do this if the underlying
status name is not very intuitive. We’ll do this a bit later in the
exercise.
He can add columns to the board. Can he add statuses? If not, why
not?
Answer: No, he cannot add statuses to this board because this

board is not using the simplified workflow. You can only add
statuses to the board on this page, if the board is using the
simplified workflow.
c. In these labs you'll log in and out as various users. To lessen the
amount of logging in and out, use different browser windows.
However, you can't just open a new tab and log in as another user,
as your original tab will be logged in as that user too. You have a
few options:
i. Open an incognito/private window in your current browser.
ii. Open a separate browser if you have another one installed.
For example, if you're using Google Chrome, open Firefox.
iii. Log out as the current user by clicking their avatar at the
bottom of the global sidebar. This method will require a lot of
logging in and out!
To simplify the instructions, when you need to log in as another user,
we'll tell you to use your incognito window, but use the method that
works for you.
3. Rename a workflow status:
The company wants to rename one of their statuses, Inspection, to In Code

Review. All their development teams are doing more types of code review
now in this step so the Inspection name has become obsolete. And they feel
the new name will be easier to understand, especially for non-developers
who may view the board.
Be careful when renaming statuses as this will affect any filters created
using the existing status. Ensure everyone is aware of the change.
Ensure your status and transition names are intuitive. People should never

have to wonder what a status means or which workflow transition to use
next.
a. Since only Jira admins can access Jira administration and update
statuses, open a new incognito browser window, go to your site URL
and log in as Alana Grant. Use the email address that corresponds
to his name and the password that you should have received.
b. To quickly navigate to the Statuses page, type a period/full stop (.) or
gg then type statuses and press return to select Statuses. (Or you
can click Settings (cog icon) in the menu and go to Issues then
Statuses.)
c. On the Statuses page, note the Category column.
The categories – To Do, In Progress, and Done – help you identify

where issues are in their lifecycle, particularly in places where a
large number of issues are rolled up e.g. Version Details page and
Sprint Health gadget. The category is also used to map statuses to
columns when creating a new board.
d. Scroll down and view the Inspection status.
What should you do before renaming a status?
Answer: Before renaming a status, always check to see if it’s in use

by another workflow. Statuses can be shared by many workflows. In
this case, there’s only one associated workflow, TIS DEV workflow.
You can check this by clicking the 1 associated workflow link. You
also want to think about whether the original status might want to
be used again in the future. In this case it won’t as they’ve changed
their type of code review. If another workflow is using the status or it
might be used in the future, you’d need to create a new status.
e. Click Edit for the Inspection status and enter:

i. Name: In Code Review
ii. Description: Issue is in code review
iii. Category: Leave as In Progress
iv. Click Update.
f. Confirm the status has been changed on the Statuses page.

g. To confirm the status has changed in the workflow, click Workflows
in the administration sidebar to view the Workflows administration
page.
h. View the TIS DEV workflow in diagram mode and confirm the new
status name.

i. Click Text to change to text mode. Note that the step still uses the
old name. Let’s update this also to avoid confusion for future editors
of this workflow.
j. Click Edit to edit this workflow.
Note that you’re now editing a draft (inactive) version of this

workflow and not the live workflow. No changes are made to the live
workflow until you publish this draft.
k. Click Edit on the Inspection step.

l. Change the Step Name to In Code Review and click Update.
m. Confirm the step name and the linked status name are now the
same.
n. Click Publish Draft to publish the draft workflow and make it active.
Each time you publish a draft workflow you’re given the option to
create a backup copy. This is a good idea if you want to save the
original workflow for later re-use or if you’re making a lot of changes
and you may need to roll them back.
o. Save a backup copy if you wish, then click Publish.
4. Configure the project’s board:

a. Navigate to the Teams in Space project’s board, TIS Scrum. (Click
Projects > Teams in Space.)
What needs to be done now?
Answer: You need to rename the column heading to match the

status. Recall that they can be different but for ease of use we’ll
rename both the status and the column.
b. Configure the board by clicking … > Board settings at the top right
corner.
c. On the Column Management page, click the column name
Inspection and change it to In Code Review.
d. Return to the board (click Back to board) and confirm it now has the
new heading.
e. Open one of the issues in this column.
f. Note the IN CODE REVIEW status shown in the issue. Open the
Status menu and select View Workflow.

g. Confirm you now see the IN CODE REVIEW status.
You can disable the View Workflow link in issues by removing users
(ideally by using project roles) from the View Read-Only Workflow
permission in the permission scheme used by the project.
h. Close this workflow window.
Exercise 2 – Updating a Workflow Scheme

on page 15.
1. View a simplified workflow:

a. Continuing as the Jira admin, Alana Grant, navigate to the
Workflows Jira administration page.
b. View the inactive workflow, Scrum Software Simplified Workflow.
This workflow was copied from a Scrum Software project. It’s the
default workflow for that type of project.
How do you know it’s a simplified workflow?
Answer: Because all statuses can transition to all other statuses.

Note the All next to each status in diagram mode indicating they are
all global transitions. And in text mode, the transition ids are
identical for each step. For example, the In Progress transition has
the id of 21 in each step.
c. Note that you can directly edit an inactive workflow. Don’t make any
changes here.
2. Update a workflow scheme:

Only certain issue types in the Teams in Space project need to follow
the TIS DEV workflow. For example, simple tasks such as editing a
design spec don’t need to go through code review. These tasks can use
the Scrum Software Simplified Workflow.
What issue types are used in the Teams in Space project?

Answer: Bug, Epic, Story, Sub-task, and Task issue types.
a. Update the Teams in Space workflow scheme so the issue types

Epic, Sub-task, and Task use the Scrum Software Simplified
Workflow.
b. Publish the workflow scheme to make the draft workflow scheme
active in the project.
c. Choose the In Progress status to replace the IN CODE REVIEW status
for epics, tasks and sub-tasks.
Note the 0 next to each issue type which indicates there are no
issues currently in the IN CODE REVIEW status.
d. Associate when issue migration is complete.
3. Verify the workflows on the board:

a. Now we need to add a task to the board to verify the simplified
workflow. On the Teams in Space project’s Backlog page, drag the
task, TIS-88, from the backlog up into the current sprint.
b. View the board and confirm you see the new issue on the board.
Which columns on the board should you be able to drag it to? Test
by dragging the issue over the other columns but leave it in the To
Do column.
Answer: You can drag the new issue to the In Progress or Done
column. You cannot drag it to the In Code Review because that
status is not in the workflow that this issue, a Task, is using.
Which column(s) on the board should you be able to drag the story
(TIS-84) in the To Do column to? Test by dragging the story over the
other columns but leave it in the To Do column.
Answer: You can only drag a story in the To Do column to the In

Progress column because these issues are using the TIS DEV
workflow which has a linear progress. Issues in the To Do status can
only transition to the In Progress status.

4. Verify the workflows by viewing issues of different types:
a. Open the task (TIS-88) and confirm that you see the transition
buttons for all three statuses – To Do, In Progress, and Done – in the
issue.
b. View the workflow for the issue and confirm it’s using the Scrum
Software Simplified Workflow.
c. Open one of the other issues on the board in the To Do column.
Confirm you see only the Start progress transition button and that
it’s using the TIS DEV workflow.
1. View a simplified workflow:
a. Continuing as the Jira admin, Alana Grant, navigate to the
Workflows Jira administration page.
b. Expand the Inactive section at the bottom of the page and edit the
Scrum Software Simplified Workflow. Click Diagram to view it in
diagram mode.
This workflow was copied from a Scrum Software project. It’s the
default workflow for that type of project.
How do you know it’s a simplified workflow?
Answer: Because all statuses can transition to all other statuses.

Note the All next to each status indicating they are all global
transitions.
c. Click Text to view the steps in the workflow.
How do you know it’s a simplified workflow in this view?
Answer: Because the transition ids are identical for each step. For
example, the In Progress transition has the id of 21 in each step.
d. Note that you can directly edit an inactive workflow. Don’t make any
changes here.

2. Update a workflow scheme:
Only certain issue types in the Teams in Space project need to follow
the TIS DEV workflow. For example, simple tasks such as editing a
design spec don’t need to go through code review. These tasks can use
the Scrum Software Simplified Workflow.
a. Navigate to the Teams in Space project settings.

b. On the project settings Summary page, view the issue types and
workflow used in this project.
What issue types are used in the Teams in Space project?
Answer: Bug, Epic, Story, Sub-task, and Task issue types.
c. Click the Teams in Space workflow scheme to edit it.
d. Click Add Workflow in the top left corner and select Add Existing.
e. Select Scrum Software Simplified Workflow then click Next.
f. The only issue types that need to use the TIS DEV workflow and go
through code review are Bug and Story. Select the three remaining
issue types for this project – Epic, Sub-task, and Task - to use the
simplified workflow. Click Finish.
g. Confirm the Teams in Space workflow scheme now looks like this:
h. Click Publish to make the draft workflow scheme active in the

project.

i. Here you choose the status to replace the IN CODE REVIEW status
for epics, tasks and sub-tasks. Select In Progress for them.
Note the 0 next to each issue type which indicates there are no
issues currently in the IN CODE REVIEW status.
j. Click Associate and when issue migration is complete, click

Acknowledge.
You can also update the Teams in Space workflow scheme from the
Jira administration pages.
3. Verify the workflows on the board:

a. Now we need to add a task to the board to verify the simplified
workflow. Navigate to the Teams in Space project’s Backlog page.
b. Drag the task, TIS-88, from the backlog up into the current sprint.
c. Click Confirm on the Move issue dialog. You should now see the task
in the sprint.
d. Click Active Sprints in the sidebar to view the board and confirm you
see the new issue on the board.
Which columns on the board should you be able to drag it to? Test
by dragging the issue over the other columns but leave it in the To
Do column.
Answer: You can drag the new issue to the In Progress or Done
column. You cannot drag it to the In Code Review because that
status is not in the workflow that this issue, a Task, is using.
Which column(s) on the board should you be able to drag the story
(TIS-84) in the To Do column to? Test by dragging the story over the
other columns but leave it in the To Do column.
Answer: You can only drag a story in the To Do column to the In

Progress column because these issues are using the TIS DEV
workflow which has a linear progress. Issues in the To Do status can
only transition to the In Progress status.
4. Verify the workflows by viewing issues of different types:

a. Open the task (TIS-88) in a new browser tab and confirm that you
see all three statuses in the transition menu – To Do, In Progress, and
Done – in the issue.

b. Click the View workflow link and confirm you see the Software
Simplified Workflow.
c. Close the window and open one of the other issues on the board in
the To Do column. Confirm you see only the Start progress transition
button.
d. Click the View Workflow link and confirm you see the TIS DEV
workflow.
e. Close the workflow window.
Congratulations on completing the lab!

Lab 2 Appendix
Further Reading
Reference URL
Workflows http://go.atlassian.com/cloud_workflows
Using the http://go.atlassian.com/cloud_simplifiedwf

Simplified
Workflow
Best Practices
Pitfall Example Use Case Best Practice
Workflows are You make a number of Don’t forget to publish

not getting requested changes to the your changes to a live
updated after you deployment workflow but workflow. When you
make changes. users are complaining they’re edit a live workflow
not seeing the changes. This you’re actually editing a
is because the workflow edits draft copy of the
were never published. workflow and your
changes don’t go live
until you publish it.
Workflows are Suddenly users are not able Only Jira admins can
performing in to transition issues to In fully edit workflows.
unexpected and Progress. This is because an Ensure that the users
incorrect ways. inexperienced user edited the who have this
transition in the workflow permission are aware of
and made a mistake. workflow editing best
practices.
Inadvertently You rename a status that’s Before renaming a

changing another used in your project’s status, always check to
project’s workflow. But you didn’t see if it’s in use by
workflow status realize the status was shared another workflow.
when you with many other projects’ Statuses can be shared
shouldn’t have. workflows and now they’re by many workflows.
upset because they want to

continue to use the old status

name.
Users don’t A writer has created a draft Ensure your status and
understand what document and wants to send transition names are
a status means it for review. In the issue, they intuitive. People should
or which see two transition buttons never have to wonder
workflow ‘Submit’ and ‘Send’. They are what a status means or
transition to use. confused about which one to which workflow
use. transition to use next.

Lab 3 – Creating Conditions & Validators
Scenario
Here you create a condition to ensure that only certain users can send issues for
code review in the Teams in Space project. Only developers in the project who own
the issue or project admins should be able to execute this transition.
You also create a validator that requires a comment when an issue has failed code
review and is sent back to the developer for more work. This is so the reviewer can
enter the reason for failure. To do this you add a simple transition screen.
Optionally, you troubleshoot a workflow problem.
You perform these tasks as the Jira admin as they’re the only ones that can add
conditions and validators to workflows.
Exercise 1 – Adding Conditions

on page 24.
1. Add conditions to workflow:

a. Log in to Jira as Alana Grant.
b. Edit the TIS DEV workflow and view the transitions.
If we want to ensure only the right people can submit issues for code
review, which transition should we add the conditions to?
Answer: To ensure only the right people can submit issues for code
review, you would add the transitions to the Ready for review
transition.
c. Edit the Ready for review transition and view the available
conditions.
We want the only people who can execute this transition to be

either the owner of the issue who’s a developer or a project admin.
Which conditions should you use?
Answer: The Only Assignee Condition ensures the issue is assigned

to the user. Ensuring the assignee is a developer could be achieved
by using either the User Is In Any Groups or Users Is In Any Roles
condition, depending on how the project is set up. It’s a best practice

to use roles as this allows you to have different users assigned to
the role on a project by project basis. And this project has been set
up with specific users in the Developers project role so we’ll use User
Is In Project Role. You also use User Is In Project Role to test for the
project admin role.
d. Add a condition that the user has to be EITHER the project admin OR
user is (the assignee AND in the Developers role).
Add the project admin condition first as you need to have at least
one existing condition before you can create a grouped condition.
And ensure you change the outer condition (at the top) to be Any of
the following conditions.
2. Publish the draft and save a backup copy.
When first editing an existing workflow it’s always a good idea to

save a backup copy in case something goes wrong and you need to
revert back to the original or to keep a copy of the original for re-use.
You’ll find your backup in the inactive workflows section.
3. Verify the conditions:

a. First, view who belongs to which roles in the Teams in Space project.
You’ll be testing your conditions as Alana Grant, Jennifer Evans and

Harvey Jennings. What roles do they have in this project?
Answer: Alana Grant has the Developers role. She also has the
Administrators role as she’s a member of the jira-administrators
group. Jennifer Evans has the Developers role. And Harvey Jennings
doesn’t have any roles in this project.
b. Open the issue, TIS-85 and verify it’s using the TIS DEV workflow.
What status is the issue in?
Answer: The issue is in the IN PROGRESS status.
Can Alana see the Ready for review transition button? If so, why and
if not, why not?

Answer: Yes, the Ready for review transition button is visible to
Alana. She can see this, even though she’s not the assignee, because
she’s a project admin. That is, she’s a member of the project’s
Administrators role.
c. Log in as Harvey Jennings.

d. Open TIS-85 again.
Can Harvey see the Ready for review transition button? If so, why and if
not, why not?
Answer: No, the Ready for review transition button is not visible. Harvey
cannot execute this transition because he’s not a member of the
project’s Administrators or Developers roles, nor the assignee.
e. Log in as Jennifer Evans.

f. Open TIS-85 again.
Can Jennifer see the Ready for review transition button? If so, why and
if not, why not?
Answer: Yes, the Ready for review transition button is visible to Jennifer.
She can execute this transition because she’s a member of the project’s
Developers role and she’s the assignee.
g. Confirm Jennifer can execute the Ready for review transition. Now
you see the issue is in the IN CODE REVIEW status.
h. Optionally, view the project’s board and confirm TIS-85 has moved to
the In Code Review column.

1. Add conditions to workflow:
a. Log in to Jira as Alana Grant, the Jira admin.
b. Navigate to the Teams in Space project settings Workflows page
and edit the TIS DEV workflow.
c. View diagram mode and check Show transition labels.
If we want to ensure only the right people can submit issues for code
review, which transition should we add the conditions to?
Answer: To ensure only the right people can submit issues for code
review, you would add the conditions to the Ready for review
transition.
d. Click the Ready for review transition and then click the Conditions
link to add conditions to this transition.
e. On the Conditions tab of the transition page, click Add condition and
view the available conditions.
We want the only people who can execute this transition to be

either the owner of the issue who’s a developer or a project admin.
Which conditions should you use?
Answer: The Only Assignee Condition ensures the issue is assigned

to the user. Ensuring the assignee is a developer could be achieved
by using either the User Is In Any Groups or Users Is In Any Roles
condition, depending on how the project is set up. It’s a best practice
to use roles as this allows you to have different users assigned to
the role on a project by project basis. And this project has been set
up with specific users in the Developers project role so we’ll use User
Is In Project Role. You also use User Is In Project Role to test for the
project admin role.
We want the conditions to be EITHER user is project admin OR user

is (assignee AND in Developers role).
f. First, we’ll add the project admin condition as you need to have at
least one existing condition before you can create a grouped
condition. Select User Is In Project Role and click Add.
On the Add Parameters To Condition page, ensure Administrators is

selected and click Add.
g. Now you see the first condition. Click Add condition to add the
second one which will be a grouped condition.
i. Select Only Assignee Condition and click Add.

ii. Mouse over the assignee condition row and click the Add
grouped condition icon.
iii. Add the User Is In Project Role conditions select the

Developers project role and click Add.
h. Now you see your grouped condition.
If you left your condition like this, who could transition issues?
Answer: As both the grouped and outer condition are using All of the
following conditions the user would have to meet all three of them.
They would have to be the assignee and also be in both the
Developers and Administrators roles. This is too restrictive for our
requirement.
i. Change the outer condition (at the top) to be Any of the following
conditions. Now the user can be EITHER the assignee and a
developer OR a project admin.
2. Publish draft:
a. To publish the draft workflow and make it active, click Publish Draft.
b. Select Yes to save a backup copy then click Publish.
When first editing an existing workflow it’s always a good idea to

save a backup copy in case something goes wrong and you need to
revert back to the original or to keep a copy of the original for re-use.
You’ll find your backup in the inactive workflows section.
c. Your changes are now active. See the ACTIVE indicator next to the
workflow name.
3. Verify the conditions:

a. First, let’s view who belongs to which roles in the Teams in Space
project. Navigate to the project settings People page.

You’ll be testing your conditions as Alana Grant, Jennifer Evans and
Harvey Jennings. What roles do they have in this project?
Answer: Alana Grant has the Developers role. She also has the
Administrators role as she’s a member of the jira-administrators
group. Jennifer Evans has the Developers role. And Harvey Jennings
doesn’t have any roles in this project.
b. Find and open the Teams in Space issue, TIS-85.

c. Click View Workflow in the status menu to verify it’s using the TIS
DEV workflow.
d. Close the view workflow pop up.
What status is the issue in?
Answer: The issue is in the IN PROGRESS status.

Can Alana see the Ready for review transition button? If so, why and
if not, why not?
Answer: Yes, the Ready for review transition button is visible to

Alana. She can see this, even though she’s not the assignee, because
she’s a project admin. That is, she’s a member of the project’s
Administrators role.
e. Log out and back in as Harvey Jennings.

f. Open TIS-85 again.
Can Harvey see the Ready for review transition button? If so, why and if
not, why not?
Answer: No, the Ready for review transition button is not visible. Harvey
cannot execute this transition because he’s not a member of the
project’s Administrators or Developers roles, nor the assignee.
g. Log out and back in as Jennifer Evans.

h. Open TIS-85 again.
Can Jennifer see the Ready for review transition button? If so, why and
if not, why not?
Answer: Yes, the Ready for review transition button is visible to Jennifer.
She can execute this transition because she’s a member of the project’s
Developers role and she’s the assignee.
i. Click the Ready for review transition button and confirm Jennifer can
execute the transition. Now you see the issue is in the IN CODE
REVIEW status.
j. Optionally, view the project’s board and confirm TIS-85 has moved to
the In Code Review column.
k. Log out as Jennifer.
Exercise 2 – Adding Validators

on the next page.

1. Create a transition screen:
Currently the TIS DEV workflow doesn’t have any transition screens.
Since we want to make a comment mandatory when transitioning an
issue back to the developer from code review, we first need to create a
screen.
a. Log in as Alana Grant, the Jira admin.

b. From the Screens Jira administration page add a new screen named
Comment Screen with a description of Add comments during Code
review failed transition.
c. On the Configure Screen page, don’t add any fields to the screen.
2. Add the screen to a transition:

a. Edit the TIS DEV workflow.
b. Add the new Comment Screen to the Code review failed transition.
3. Add a validator to a transition:

a. View the available validators to add to the Code review failed
transition.
Note there’s a permission validator here. Recall that there’s also a

permission condition. Always use the permission condition to check
a user’s permissions. (This permission validator is here for historical
reasons.)
b. Add the Field Required Validator to the Code review failed

transition. Make the Comment field required.
c. Publish your draft and save a backup copy if you wish.
4. Verify the validator:

a. Navigate to the Teams in Space project’s board. Note TIS-82 which is
currently in code review.
b. Log in as Jennifer Evans.
c. Open TIS-82 and click Assign to me

d. Execute the Code review failed transition.
e. Without entering a comment, click Code review failed on the
comment screen. You should see a message that a comment is
required.
f. Enter any comment. For example, Remove jokes from comments
(even though they were funny!). Click Code review failed.
g. Now the transition screen should disappear and the issue should be
back to IN PROGRESS.
h. Optionally, view the board and confirm the issue is now in the In
Progress column.
Typically, when a reviewer is reviewing code they assign the issue to

themselves. In this case, the reviewer has entered why the issue
failed code review and sent it back to IN PROGRESS for the
developer to do more work. What else could be added to this
transition to automate things?
Answer: Since the developer now needs to do more work on the

issue, the assignee should be changed from the reviewer to the
developer. We’ll do that in the next lab on post functions.
To start the optional exercise, go to page 32.
1. Create a transition screen:
Currently the TIS DEV workflow doesn’t have any transition screens.
Since we want to make a comment mandatory when transitioning an
issue back to the developer from code review, we first need to create a
screen.

b. Click Settings (cog icon) in the main menu and select Issues then
Screens. Click Add screen.

c. On the Add screen dialog, enter:
i. Name: Comment Screen
ii. Description: Add comments during Code review failed
transition
iii. Click Add
d. On the Configure Screen page, don’t add any fields to the screen.
2. Add the screen to a transition:

a. Navigate to the Workflows Jira administration page and edit the TIS
DEV workflow.
b. In diagram mode, select the Code review failed transition and click
Edit.
c. Select the Comment Screen you just created from the Screen
dropdown. Click Save.
d. You now see the screen listed for Code review failed.
3. Add a validator to a transition:

a. Ensure the Code review failed transition is still selected and click
Validators.
b. On the Validators tab, click Add validator.
c. Select the Field Required Validator.

Note there’s a permission validator here. Recall that there’s also a
permission condition. Always use the permission condition to check
a user’s permissions. (This permission validator is here for historical
reasons.)
d. Click Add.
e. On the Add Parameters to Validator page, select Comment from the
Available fields list and click Add>>. Now you should see Comment in
the Required fields list. Click Add.
You now see your validator set to require the Comment field for the
Code review failed transition.
f. Publish your draft and save a backup copy if you wish.
4. Verify the validator:

a. Log in as Jennifer Evans.
b. Navigate to the Teams in Space project’s Active sprints board. Note
TIS-82 which is currently in code review.
c. Open TIS-82 and click on the assignee and select Assign to me.
d. Click the Code review failed transition.
e. Without entering a comment, click Code review failed on the
comment screen. You should see a message that a comment is
required.
f. Enter any comment. For example, Remove jokes from comments
(even though they were funny!). Click Code review failed.
g. Now the transition screen should disappear and the issue should be
back to IN PROGRESS.
h. Optionally, view the board and confirm the issue is now in the In
Progress column.
Typically, when a reviewer is reviewing code they assign the issue to

themselves. In this case, the reviewer has entered why the issue
failed code review and sent it back to IN PROGRESS for the
developer to do more work. What else could be added to this
transition to automate things?
Answer: Since the developer now needs to do more work on the

issue, the assignee should be changed from the reviewer to the
developer. We’ll do that in the next lab on post functions.

Optional Exercise 3 – Troubleshooting a Workflow Problem
on page 36.
1. Explore the problem:
Harvey Jennings is a Content Manager. He’s not a developer in the

Teams in Space project yet he is able to close issues in that project. Only
users in the Developers project role should be able to close issues as
defined in the permission scheme.

b. View the Teams in Space project settings.
What controls who can access this project and what they can do
within the project?
Answer: The permission scheme controls who can access this project
and what they can do within the project.
Which permission scheme is this project using?
Answer: The Default Permission Scheme.
c. Open the Default Permission Scheme and view the permissions for
Close Issues and Resolve Issues.
Who can close and resolve issues in each project that uses this
scheme?
Answer: Members of the Developers project role can close and

resolve issues.
Scroll down and note the Transition Issues permission. This is

required for any users to be able to execute a transition.
Who can transition issues in each project that uses this scheme?
Answer: Members of the Users project role can transition issues.
Harvey Jennings is in the jira-developers and jira-users groups. What

is his role in the Teams in Space project?

Answer: Harvey Jennings is only in the Users project role because
he’s a member of the jira-users group. He’s not in the Developers or
Administrators roles for this project. Recall that only members of the
Developers project role had permission to close and resolve issues.
d. Log in as Harvey Jennings and navigate to the Teams in Space

project’s board.
e. Drag TIS-86 from In Code Review to Done.
Was Harvey able to close the issue?
Answer: Yes, Harvey did successfully close the issue. If you open the
issue the status is DONE.
f. Troubleshoot this issue and try to figure out why Harvey can close
issues in this project. Then fix the problem by editing the workflow.
There’s a hint on the next page and the answer is on the page after
that.

2. Hint: You need to create two conditions for the final transition.

3. Resolve the problem – create two conditions for the Code review passed
transition so only users with the Close Issues and Resolve Issues
permissions can execute the transition.
4. Verify your resolution:

a. On the Teams in Space board, reopen TIS-86 by dragging it back to
the To Do column. Then drag it to In Progress and then In Code
Review.
b. Log in as Harvey Jennings and return to the board.
Can you drag TIS-86 to the Done column?
Answer: No, Harvey can no longer close issues. Problem resolved!
Did you notice anything else that needs to be fixed? And if so, how?
If you wish to troubleshoot this in Jira, you’ll need to log in as Alana
Grant.
Answer: Harvey can still drag this issue to In Progress. If you only
wanted Developers in the project to move issues on the board you
could resolve that in a couple of ways. You could edit the permission
scheme and limit the Transition Issues permission to the Developers
project role (currently it’s set to Users.) But what could be a problem
with doing this?
Answer: This permission scheme is shared by 4 projects and

any changes you make will apply to those projects as well.
The other projects may need Transition Issues set to Users.
The other way to resolve this would be to add a condition to each

transition. For example, only Developers can execute the transition
(User Is In Project Role condition). You don’t need to fix that now
(unless you have the time and really want to!)

1. Explore the problem:
Harvey Jennings is a Content Manager. He’s not a developer in the

Teams in Space project yet he is able to close issues in that project. Only
users in the Developers project role should be able to close issues as
defined in the permission scheme.

b. Navigate to the Teams in Space project settings. View the Summary
page.
What controls who can access this project and what they can do
within the project?
Answer: The permission scheme controls who can access this project
and what they can do within the project.
Which permission scheme is this project using?
Answer: The Default Permission Scheme.
c. In the Permissions section, click to open the Default Permission

Scheme.
d. Scroll down to Issue permissions and view the permissions for Close
Issues and Resolve Issues.
Who can close and resolve issues in each project that uses this
scheme?
Answer: Members of the Developers project role can close and

resolve issues.
Scroll down and note the Transition Issues permission. This is

required for any users to be able to execute a transition.
Who can transition issues in each project that uses this scheme?
Answer: Members of the Users project role can transition issues.
e. Navigate to the People page in the Teams in Space project.
Harvey Jennings is in the jira-developers and jira-users groups. What

is his role in the Teams in Space project?

Answer: Harvey Jennings is only in the Users project role because
he’s a member of the jira-users group. He’s not in the Developers or
Administrators roles for this project. Recall that only members of the
Developers project role had permission to close and resolve issues.
f. Log in as Harvey Jennings and navigate to the Teams in Space

project’s board.
g. Drag TIS-86 from In Code Review to Done.
Was Harvey able to close the issue?
Answer: Yes, Harvey did successfully close the issue. If you open the
issue the status is DONE.
h. Troubleshoot this issue and try to figure out why Harvey can close
issues in this project. Then fix the problem by editing the workflow.
There’s a hint on the next page and the answer is on the page after
that.

2. Hint: You need to create two conditions for the final transition.

3. Resolve the problem – create two conditions so only users with the Close
Issues and Resolve Issues permissions can execute the transition.
a. Log in as Alana Grant, the Jira admin, and edit the TIS DEV workflow.
b. Click the Code review passed transition and then click the
Conditions link.
c. On the Conditions tab click Add condition.
d. Select Permission Condition and click Add.
e. On the Add Parameters To Condition page, select Close Issues and
click Add.
f. Follow these steps to add another permission condition for Resolve
Issues.
g. Publish your draft and save a backup copy if you wish.
4. Verify your resolution:

a. Navigate to the Teams in Space board.
b. Reopen TIS-86 by dragging it back to the To Do column. Then drag it
to In Progress and then In Code Review.
d. Return to the board.
Can you drag TIS-86 to the Done column?
Answer: No, Harvey can no longer close issues. Problem resolved!
Did you notice anything else that needs to be fixed? And if so, how?
If you wish to troubleshoot this in Jira, you’ll need to log in as Alana
Grant.
Answer: Harvey can still drag this issue to In Progress. If you only
wanted Developers in the project to move issues on the board you
could resolve that in a couple of ways. You could edit the permission
scheme and limit the Transition Issues permission to the Developers
project role (currently it’s set to Users.) But what could be a problem
with doing this?
Answer: This permission scheme is shared by 4 projects and

any changes you make will apply to those projects as well.
The other projects may need Transition Issues set to Users.
The other way to resolve this would be to add a condition to each

transition. For example, only Developers can execute the transition

(User Is In Project Role condition). You don’t need to fix that now
(unless you have the time and really want to!)

Lab 3 Appendix
Further Reading
Reference URL
Advanced Workflow http://go.atlassian.com/cloudadvwfs

Configuration
documentation
Common Workflow http://go.atlassian.com/wfts

Configuration
Mistakes
Best Practices
You cannot revert You made updates to an When editing an active

back to your active workflow, removing workflow and making
original workflow the Approval status and its large changes, it’s always
if changes need associated transitions. You a good idea to save a
to be rolled back. did not save a backup. Six backup copy. This way if
months later, you ever need to re-use the
requirements have workflow again, you have
changed and they now it. Also, if you made a
need approval again. mistake when editing, you
Because you didn’t keep a may need to revert back to
backup, you have to the original. You’ll find your
recreate the status and backup in the inactive
transitions all over again. workflows section.
Users from one Your Sales, Marketing, and Use project roles over
project can do HR projects share the groups, in your conditions
things in other same workflow. In that and validators. This allows
projects they workflow, there’s a you to share workflows
shouldn’t be able transition that only (and conditions/validators)
to. Or, you have to Managers in those projects across multiple projects
create separate can perform. You want to and have different users
groups for every use a group in the meet or fail the
project to use in condition. Either, you need condition/validator
conditions and to have one global depending on their
validators. And Managers group to use or

create multiple create separate manager membership in individual

conditions and groups for each project. If project roles.
validators. you created one global
group, that would mean
that Managers from one
project could execute the
transition in the other
projects. Or, if you create
separate manager groups
for each project you’d need
to put a complex condition
in the workflow that
checks whether the user is
a member of either of the
three groups. Either way is
not ideal.
Workflows A shared approvals Check whether a transition

change behavior workflow that’s used for is shared before adding
unexpectedly. approving holiday requests conditions or validators to
by the HR and product it. Ensure your conditions
teams. If someone or validators won’t impact
changes the transition other workflows
from the Requested status
to the Approve status so
that only hr-managers can
make this transition it
breaks the workflow, as no
one in the product-
managers group is able to
approve new feature
requests.

Lab 4 – Creating Post Functions
Scenario
Here you create two post functions that update the resolution field. One to set it
when the issue is done and another to clear it when the issue is reopened.
Also, you create another pair of post functions that copy field values. One copies
the assignee to the Developer field when an issue is sent for code review. The
second post function will reassign the issue back to the developer if an issue fails
code review.
Optionally, you can read up on post functions.
post functions to workflows.
Exercise 1 – Setting the Resolution in Post Functions

on page 45.
1. Create a post function to set the resolution:
It’s very important to have the resolution set when an issue is complete.
If you don't set a resolution on the final transition, then the issue isn't
considered resolved by all the Jira reports. This can be accomplished by
either having the user enter a resolution in a final transition screen or
having it set in a post function.
a. Log in to Jira as Alana Grant.

b. Edit the TIS DEV workflow.
Which transition should you edit to set the resolution?
Answer: The resolution is set when the issue is done. The transition
going into DONE is Code review passed. So, set the resolution on this
Code review passed transition. Note that some workflows are
already set up to set the resolution. For example, the Scrum
software simplified workflow that’s the default workflow for Scrum
projects is already set up to set the resolution when an issue is done
and clear it when an issue is reopened.

c. View the essential post functions for the Code review passed
transition.
d. Add an Update Issue Field post function to the Code review passed
transition. Set it to update the Resolution field with the value Done.
2. Create a post function to clear the resolution:

a. Return to editing the workflow.
Which transition should you edit to clear the resolution?
Answer: The resolution needs to be cleared when the issue is

reopened. The transition going from DONE to TO DO is Reopen. So,
clear the resolution on this Reopen transition.
b. Edit the Reopen transition.
Which post function should you use to clear the resolution?
Answer: You can actually use one of two post functions. Either the
Clear Field Value post function or the Update Issue Field post
function. We’ll use the Update Issue Field post function in this lab.
c. Add the Update Issue Field post function. Set it to update the
Resolution field with the value None.
d. Publish the draft workflow and save a backup copy if you wish.
3. Verify the resolution is being set:

a. Transition story TIS-85 to Done.
b. Open TIS-85 and confirm the Resolution field is set to Done and the
status is DONE.
c. Return to the TIS Scrum board and view the issues in the Done
column.
Why does TIS-85 have a line through its issue key and TIS-87 does
not?
Answer: When an issue has been resolved (its Resolution field has
been set), Jira displays its issue key with a line through it. Even
though TIS-87 is in the Done column its Resolution has not been set
because it was placed there before the post transition to set
resolution was added to its workflow. So even though it’s status is
DONE, the issue is not resolved as far as Jira is concerned and it will
not show up as resolved in any Jira report. Optionally, you can fix this
by dragging TIS-87 back to To Do then through each of the columns
in turn until it’s back to Done. Now it should have a line through the

issue key.
4. Verify the resolution is being cleared:
Reopen TIS-85 and confirm the Resolution field is now Unresolved, the
status is TO DO, and there’s no longer a line through the issue key.
1. Create a post function to set the resolution:
It’s very important to have the resolution set when an issue is complete.
If you don't set a resolution on the final transition, then the issue isn't
considered resolved by all the Jira reports. This can be accomplished by
either having the user enter a resolution in a final transition screen or
having it set in a post function.

b. Edit the TIS DEV workflow.
Which transition should you edit to set the resolution?
Answer: The resolution is set when the issue is done. The transition
going into DONE is Code review passed. So, set the resolution on this
Code review passed transition. Note that some workflows are
already set up to set the resolution. For example, the Scrum
software simplified workflow that’s the default workflow for Scrum
projects is already set up to set the resolution when an issue is done
and clear it when an issue is reopened.
c. Select the Code review passed transition and click the Post
Functions link.
d. Note the essential post functions that are performed by default for
this transition. Click Add post function.
e. Select the Update Issue Field post function and click Add.
f. On the Add Parameters To Function page, select Resolution for the
field to change and Done for the field value. Click Add.

g. Confirm you see your new post function setting resolution to Done.
2. Create a post function to clear the resolution:

a. Return to editing the workflow by clicking the TIS DEV workflow
(Draft) link.
Which transition should you edit to clear the resolution?
Answer: The resolution needs to be cleared when the issue is

reopened. The transition going from DONE to TO DO is Reopen. So,
clear the resolution on this Reopen transition.
b. Add a post function to the Reopen transition.
Which post function should you use to clear the resolution?
Answer: You can actually use one of two post functions. Either the
Clear Field Value post function or the Update Issue Field post
function. We’ll use the Update Issue Field post function in this lab.
c. Select the Update Issue Field post function and click Add.
d. On the Add Parameters To Function page, select Resolution for the
field to change and None for the field value. Click Add.
e. Confirm you see your new post function clearing resolution.
f. Publish the draft workflow and save a backup copy if you wish.
3. Verify the resolution is being set:

a. Transition story TIS-85 to Done by either:
i. Open TIS-85 and select the Code review passed transition
button from the status menu.
ii. Navigate to the TIS Scrum board and move TIS-85 from the In
Code Review column to the Done column.
b. Open TIS-85 and confirm the Resolution field is set to Done and the
status is DONE.

c. Return to the TIS Scrum board and view the issues in the Done
column.
Why does TIS-85 have a line through its issue key and TIS-87 does
not?
Answer: When an issue has been resolved (its Resolution field has
been set), Jira displays its issue key with a line through it. Even
though TIS-87 is in the Done column its Resolution has not been set
because it was placed there before the post transition to set
resolution was added to its workflow. So even though it’s status is
DONE, the issue is not resolved as far as Jira is concerned and it will
not show up as resolved in any Jira report. Optionally, you can fix this
by dragging TIS-87 back to To Do then through each of the columns
in turn until it’s back to Done. Now it should have a line through the
issue key.
4. Verify the resolution is being cleared:

a. Reopen TIS-85 by either dragging it into the To Do column or opening
the issue and clicking the Reopen button in the status menu.
b. Open TIS-85 and confirm the Resolution field is now Unresolved, the
status is TO DO, and there’s no longer a line through the issue key.
Exercise 2 – Copying Field Values in Post Functions

on the next page.
1. Create a post function to copy the value of Assignee to another field:
Here you add a post function to the Ready for review transition that will
copy the value of the Assignee field to the Developer field. At Teams In
Space, they always want to know what developer actually implemented
the code change but when the issue goes through code review the reviewer
reassigns the issue to themselves.
a. Edit the TIS DEV workflow.

b. Edit the Ready for review transition and add the Copy Value From
Other Field post function. Set it to copy the value from the Assignee
field to the Developer (User Picker (single user)) field.

2. Create a post function to reassign an issue:
Here you add a post function to the Code review failed transition that will
copy the value of the Developer field to the Assignee field and so reassign
the issue back to the original developer.
a. Add a post function to the Code review failed transition that copies
the value from the Developer (User Picker (single user)) field to the
Assignee field.
b. Publish the draft workflow and save a backup copy if you wish.
3. Verify the post functions:

a. Transition issue TIS-82 to IN CODE REVIEW.
b. Open TIS-82 and verify the value of Assignee, Jennifer Evans, has
been copied to the Developer field.
c. Alana will act as the reviewer here so assign the issue to her.
d. Send the issue back to the developer by executing the Code review
failed transition.
e. Confirm that the issue has been reassigned back to the original
developer, Jennifer Evans.
1. Create a post function to copy the value of Assignee to another field:
Here you add a post function to the Ready for review transition that will
copy the value of the Assignee field to the Developer field. At Teams In
Space, they always want to know what developer actually implemented
the code change but when the issue goes through code review the reviewer
reassigns the issue to themselves.
a. Continuing as Alana, edit the TIS DEV workflow.

b. Add a post function to the Ready for review transition.
c. Select Copy Value From Other Field and click Add.
d. On the Add Parameters to Function page, select the following
values:

i. Source Field: Assignee
ii. Destination Field: Developer (User Picker (single user))
iii. Option: Copy within same issue (default)
Click Add.
e. Confirm you now see the new post function to copy the value from
Assignee to Developer.
2. Create a post function to reassign an issue:
Here you add a post function to the Code review failed transition that will
copy the value of the Developer field to the Assignee field and so reassign
the issue back to the original developer.
a. Continue editing the TIS DEV workflow.

b. Add a post function to the Code review failed transition.
c. Select Copy Value From Other Field and click Add.
d. On the Add Parameters to Function page, select the following
values:
i. Source Field: Developer (User Picker (single user))
ii. Destination Field: Assignee
iii. Option: Copy within same issue (default)
Click Add.
e. Confirm you now see the new post function to copy the value from
Developer to Assignee.
f. Publish the draft workflow and save a backup copy if you wish.

3. Verify the post functions:
a. Open TIS-82 and select the Ready for review transition from the
status menu.
Verify the value of Assignee, Jennifer Evans, has been copied to the
Developer field.
b. Alana will act as the reviewer here. Click Assign to me (under
Assignee) so the issue is now reassigned to her.
c. Click the Code review failed transition button to send the issue back
to the developer. On the Code review failed transition screen, enter
any text and click Code review failed.
d. Confirm that the issue has been reassigned back to the original
developer, Jennifer Evans.

Lab 4 Appendix
Further Reading
Reference URL
Post functions http://go.atlassian.com/cloudadvwfs

documentation
Adding a http://go.atlassian.com/cloud_custom_event
custom event
Workflows http://go.atlassian.com/wfts
troubleshooting
Best Practices
Reports are not Your reports are showing It’s very important to have
correct. that no issues were the resolution set when an
resolved when some issue is complete. If you
issues were resolved. This don't set a resolution on
is because the resolution the final transition, then
was not being set on the the issue isn't considered
final transition. resolved by all the Jira
reports. This can be
accomplished by either
having the user enter a
resolution in a final
transition screen or having
it set in a post function.
Operations are You have the post function Ensure post functions are
not being that indexes an issue in the correct order.
performed before the post function
correctly in post that updates a field. So,
functions. the change is not in the
latest search index.
Actions in one You have two projects Ensure your post functions
project’s using a software won’t impact other
workflow are development workflow. workflows or projects.
causing You update the post

unwanted results function on the Code

in other projects. Review Passed transition
to send a notification to
your project’s Hipchat
room. However, the
workflow is being shared
with other projects so
you’re now receiving
notifications when issues
from other projects pass
code review.

Lab 5 –Triggering Transitions
There is no lab for this module.
Lab 5 Appendix
Further Reading
Reference URL
Configuring http://go.atlassian.com/cloud_wftriggers
Workflow Triggers
(including
Troubleshooting
Triggers)
Best Practices
Global transitions You created a commit trigger Don’t configure

are not working for a global transition that triggers for global
correctly. moves issues from whatever transitions
state they’re in to In Progress.
However, when commits are
made during the code review
phase, issues shouldn’t return
to in progress but stay where
they are.
Post functions There is no matching email If you’re using post

requiring user address in Jira for the functions that require
data are not developer who does a merge in user information,
executing Bitbucket (and so triggers the ensure your users
correctly. transition in Jira). Because of won’t be mapped as
this, the post function that anonymous.
needs the username, won’t
execute correctly.

Conditions and You’ve edited a transition and Don’t add permissions,

validators are not added conditions, validators, conditions, and
working. and a trigger. When a user validators to
triggers the transition from transitions that have
Bitbucket the conditions and triggers. These are
validators are not working. ignored for automatic
transitions.

Lab 6 – Extending Workflows with Properties
Scenario
Here you restrict who can delete and edit issues once they’re done in the Teams in
Space project. You also reorder the transition buttons available for in progress
issues. Optionally, you view properties in the Jira workflow.
properties to workflows.
Exercise 1 – Restricting Actions in Statuses

on page 59.
1. View project permission scheme:
Before we update the delete and edit permissions for the Done status using
properties, let’s view the project permissions.

b. Open the permission scheme the Teams in Space project uses, the
Default Permission Scheme.
c. View the permissions for Delete Issues and Edit Issues.
Who can delete and edit issues in each project that uses this
scheme?
Answer: Members of the Administrators and Developers project

roles can delete issues and edit issues.
We’re going to restrict who can delete and who can edit issues once
they’re done. Why wouldn’t we just update the permission scheme
and restrict the Delete Issues and Edit Issues permissions instead of
adding properties?
Answer: We don’t want to update the Default Permission Scheme as

this is shared with other projects. (In the Permission schemes
administration module, you can see, that the Default Permission
Scheme is used by 5 projects.) The Teams in Space project is the only
project that needs to implement stricter security for now. Also, we
want to finely control the permissions. The Delete Issues and Edit
Issues permissions in the permission scheme apply to issues in any

stage of the workflow whereas we want to control who can delete
and edit issues once they’re done.
2. View what you can do to a done issue:

a. Before editing properties, view what developers can do with a done
issue. Log in as Jennifer Evans.
b. View TIS-87 which is in the Done status.
c. Verify that she can see the Delete option for the issue (but don’t
delete the issue). Also note that she can edit done issues.
3. Restrict the deletion of done issues:

a. Log back in as Alana Grant.
b. Open TIS-87 and confirm she can also see the Delete option.
Here we restrict deletion of done issues to just project admins.

Before we can do that, we need to get the project role ID. To use a
project role in a property you need to use the project role ID, not the
name.
c. Get the project role ID:

i. Navigate to the Project roles Jira administration page.
ii. Mouse over the Edit link for the Administrators project role
and view the URL in the browser status bar. Note the number
at the end, which is the project role ID.
If you don’t see the status bar at the bottom of your browser
window, you may need to activate it. Each browser is
different but check your view options and ensure that Status
Bar is checked.

d. Edit the TIS DEV workflow and add the
jira.permission.delete.projectrole property to the DONE status with
a value of 10002.
Note that there’s no Edit link for the property. To update a

property, you have to delete it and recreate it.
e. Publish your draft workflow.

f. Verify your new property:
i. Open issue TIS-87 and confirm Alana can still see the Delete
option.
Alana is a Jira admin but she is also a project admin as the

jira-administrators group is in the Administrators project role.
If Jira admins were not in the Administrators project role,

what would you need to do to allow them to delete done
issues?
Answer: To allow the Jira admins to delete done issues, you’d

need to add another permission property. But since they don’t
have a project role you’d use jira.permission.edit.group with a
value of jira-administrators.
ii. Log in as the developer Jennifer Evans.

iii. Open TIS-87 and confirm she cannot see the Delete option
but note that she is able to edit the issue.
4. Restricting the editing of done issues:
Here we restrict editing done issues to just Jira admins. Recall from
viewing the permission scheme earlier that project admins and
members of the Developers project role can edit issues. We verified
that as a developer, Jennifer.
a. Verify project admins can edit done issues by logging in as William

Smith. He is a member of the project Administrators role (but is not a
Jira admin).
b. Open TIS-87 and confirm he can edit the issue.
c. Log in as Alana Grant.
d. Edit TIS DEV workflow and add the jira.permission.edit.group
property to the DONE status with a value of jira-administrators.
e. Publish your draft.
i. View TIS-87, which is done, and confirm Alana can still edit
the issue.

ii. Log in as the project admin William Smith and open TIS-87.
Can he edit the issue? If not, why not.
Answer: No, he cannot edit the issue because he’s a project

admin but not a Jira admin and only Jira admins can now edit
done issues.
iii. Optionally, log in as the developer Jennifer Evans and confirm
she cannot longer edit TIS-87.
Will these new restrictions apply to all issue types in this project?
Answer: No, recall that only stories and bugs use the TIS DEV
workflow. Other issues types use the Scrum Software Simplified
Workflow. We just want the restrictions for stories and bugs so
we’re only editing the TIS DEV workflow.

1. View project permission scheme:
Before we update the delete and edit permissions for the Done status using
properties, let’s view the project permissions.

b. Navigate to the Teams in Space project settings and open the
permission scheme this project uses, the Default Permission
Scheme.
c. Scroll down to Issue permissions and view the permissions (Project

settings > Permissions) for Delete Issues and Edit Issues.
Who can delete and edit issues in each project that uses this
scheme?
Answer: Members of the Administrators and Developers project

roles can delete issues and edit issues.
We’re going to restrict who can delete and who can edit issues once
they’re done. Why wouldn’t we just update the permission scheme
and restrict the Delete Issues and Edit Issues permissions instead of
adding properties?
Answer: We don’t want to update the Default Permission Scheme as

this is shared with other projects. (In the Permission schemes
administration module, you can see, that the Default Permission
Scheme is used by 5 projects.) The Teams in Space project is the only
project that needs to implement stricter security for now. Also, we
want to finely control the permissions. The Delete Issues and Edit
Issues permissions in the permission scheme apply to issues in any
stage of the workflow whereas we want to control who can delete
and edit issues once they’re done.
2. View what you can do to a done issue:

a. Before editing properties, view what developers can do with a done
issue. Log in as Jennifer Evans.
b. View TIS-87 which is in the Done status.
c. Open the Actions menu and verify you see the Delete option (but
don’t delete the issue).

Also note that she can edit done issues.
3. Restrict the deletion of done issues:

a. Log in as Alana Grant.
b. Open TIS-87 and confirm she can also see the Delete option under
Actions.
Here we restrict deletion of done issues to just project admins.

Before we can do that, we need to get the project role ID. To use a
project role in a property you need to use the project role ID, not the
name.
c. Get the project role ID:

i. Navigate to Jira administration > System > Project roles.
ii. Mouse over the Edit link for the Administrators project role
and view the URL in the browser status bar. Note the number
at the end, which is the project role ID.
If you don’t see the status bar at the bottom of your browser
window, you may need to activate it. Each browser is

different but check your view options and ensure that Status
Bar is checked.
d. Edit the TIS DEV workflow.

e. In diagram view, click the DONE status then the Properties link.
f. Add a property to a status:
i. Property Key: jira.permission.delete.projectrole
ii. Property Value: 10002
iii. Click Add.
Note that there’s no Edit link for the property. To update a

property, you have to delete it and recreate it.
g. Return to the workflow (click workflow steps) and publish your draft.
h. Verify your new property:
i. Open issue TIS-87 and confirm Alana can still see the Delete
option under More.
Alana is a Jira admin but she is also a project admin as the

jira-administrators group is in the Administrators project role.
If Jira admins were not in the Administrators project role,

what would you need to do to allow them to delete done
issues?
Answer: To allow the Jira admins to delete done issues, you’d

need to add another permission property. But since they don’t
have a project role you’d use jira.permission.edit.group with a
value of jira-administrators.
ii. Log in as the developer Jennifer Evans.

iii. Open TIS-87 and confirm she cannot see the Delete option
under Actions.
Note that she still can edit the issue.
4. Restricting the editing of done issues:
Here we restrict editing done issues to just Jira admins. Recall from
viewing the permission scheme earlier that project admins and
members of the Developers project role can edit issues. We verified
that as a developer, Jennifer.
a. Verify project admins can edit done issues by logging in as William

Smith. He is a member of the project Administrators role (but is not a
Jira admin).

b. Open TIS-87 and confirm he can edit the issue.
c. Log in as Alana Grant.
d. Edit TIS DEV workflow and add a new property to the DONE status:
i. Property Key: jira.permission.edit.group
ii. Property Value: jira-administrators
iii. Click Add.
e. Return to the workflow (Workflow steps) and publish your draft.

i. View TIS-87, which is done, and confirm Alana can edit the
issue.
ii. Log in as the project admin William Smith.
iii. Open TIS-87.
Can he edit the issue? If not, why not.
Answer: No, he cannot longer edit the issue because he’s a

project admin but not a Jira admin and only Jira admins can
now edit done issues.
iv. Optionally, log in as the developer Jennifer Evans and confirm

she cannot longer edit issue TIS-87.
Will these new restrictions apply to all issue types in this project?
Answer: No, recall that only stories and bugs use the TIS DEV
workflow. Other issues types use the Scrum Software Simplified
Workflow. We just want the restrictions for stories and bugs so
we’re only editing the TIS DEV workflow.
Exercise 2 – Viewing Properties in the Jira Workflow

Instructions
1. Log in as Alana Grant.
2. Navigate to the Workflows Jira administration page.
3. Expand the Inactive workflow section and edit the Copy of jira system
workflow. We’re looking at a copy of the jira workflow as you cannot edit
the original jira workflow.
This can be a useful starting workflow to customize if it meets your needs.
4. View the properties for the CLOSED status.
What does this property do?

Answer: When the jira.issue.editable property is set to false for the CLOSED
status, any issue that is closed is no longer editable by anyone.
Assuming you didn’t want closed issues to be edited by users, when might
you not want to do this?
Answer: When you want the option for Jira admins to edit closed issues by
using Bulk Edit. For example, company X wasn’t using versions when they
started with Jira, just another custom field. At some point, they decide to
use the feature and want to add versions to issues that shipped a long time
ago. Or perhaps a project is splitting or consolidating components or
versions or adding new labels, components etc. This helps with reporting
and organizing issues.

Lab 6 Appendix
Further Reading
Reference URL
Available Jira workflow http://go.atlassian.com/cloud_wfprops

properties
Best Practices
Spending too Make editing of issues in a Think if a property is

much time certain status available to absolutely necessary
adding a certain set of users by before adding it.
properties. adding in several
jira.edit.permission.user
properties when you could
add the users to a group
and then add a single
jira.edit.permission.group
property.
You’re having a Using the jira.i18n.submit Keep properties simple

hard time property to rename a and use them sparsely.
maintaining transition button. This
certain properties requires you to make
as they are changes to the language
complex. jar files used by the Jira
server. As transition
buttons automatically take
their value from the
transition name, you could
more simply rename the
transition to update the
button text.
Properties are not Using a Test properties in a

tested before jira.permission.delete.group development environment
they go live and = senior-managers property before going live so you
cause a workflow to allow only certain users

to function in an in the organization to can ensure that they work

incorrect way. delete closed issues. as expected.
However, when you add
the property, you discover
that the relevant users
have not been added to the
senior-managers group
and so cannot delete the
issues.

Lab 7 –Taking It to the Next Level
Scenario
The Marketing team at Teams in Space creates blogs for customers to increase
engagement, alert them of new releases and features, etc. Up to now they've been
using a simple content management workflow. But now they want to have each
blog approved by the Content Manager before publication.
Here you take a basic content management workflow and transform it into a
workflow that fits the needs of the business by adding a reusable approvals and
rejection process.
For this lab, we encourage you do follow the high-level instructions. There we give
the requirements and you decide out how to implement them in Jira.
You perform these tasks as the Jira admin as they’re the only ones that can
perform advanced workflow editing.
Exercise 1 – Adding Approval to a Workflow

on the next page.
High-level Requirements:
The current Marketing workflow (Content Management) is shown below. They
now require blogs to be approved before they’re published. Even though this
workflow is fairly simple, the Jira admin wants to keep workflows as simple as
possible so the approval should be implemented without adding any new
statuses. Also, HR shares this workflow and does not require approval so any
changes should not affect the HR workflow.

1. Users want to be able to see if an issue is approved when they view an
issue. Also, you need a way to determine when an issue is approved (since
you’re not using a status).
2. The HR workflow should not be affected by changes to the Marketing
workflow.
3. Add approval to the workflow without adding a new status.
4. Only Content Managers should be able to approve publication of blogs.
5. When a blog is approved for publication, indicate that it has been approved.
6. Blogs should only be able to be published once they have been approved.
7. Only Content Managers should be able to publish blogs.
8. Verify the workflow by testing it as a Content Manager and a user who is
not a Content Manager.
Hints (if you need them)

1. Users want to be able to see if an issue is approved when they view an
issue. Also, you need a way to determine when an issue is approved (since
you’re not using a status).
o Hint: Before editing the workflow, if an Approved field doesn’t exist,
you need to create it. Also, you need to ensure this field is on the
View Issue screen used by Marketing issues in the Content
Management workflow.
2. The HR workflow should not be affected by changes to the Marketing
workflow.
o Hint: Copy the workflow.
3. Add approval to the workflow without adding a new status.
o Hint: add a self-reflecting transition.
4. Only Content Managers should be able to approve publication of blogs.
o Hint: Add a condition to your new transition.
5. When a blog is approved for publication, indicate that it has been approved.
o Hint: Add a post function to set the flag.
6. Blogs should only be able to be published once they have been approved.
o Hint: Add a condition when publishing that checks the flag.
7. Only Content Managers should be able to publish blogs.
o Hint: Add a condition when publishing.
1. Set up for editing the workflow:
Before editing workflows, plan your changes and think about all the Jira
resources that you’ll be using in conditions, etc. This will make the actual
editing of the workflow much faster and easier.

The Jira admin wants to have an Approved flag (to be used in a condition)
and also wants to see this field on the issue once it’s approved. What might
we need to create before editing the workflow?
Answer: Before editing the workflow, if an Approved field doesn’t exist, we

need to create it. Also, we need to ensure this field is on the View Issue
screen used by Marketing issues in the Content Management workflow.
Use flags to mark issues for easy filtering on certain criteria or to restrict
issues of a certain criteria from being transitioned. Here we’ll use the
Approval flag as an alternative to a new status and to restrict when a blog
can be published.

b. Navigate to the Custom fields Jira administration page (under
Issues).
Do you see a custom field called Approved?
Answer: No, there’s no Approved custom field so we need to create

it.
c. Click Create custom field and then configure with:

i. Select Checkboxes and click Next.
ii. On the Configure ‘Checkboxes’ Field dialog:
1. Name: Approved
2. Description: Approved flag
3. Options: Yes
4. Click Add and then Create.
iii. Now you choose the screens to have this field appear on. On
the Associate field Approved to screens page, scroll down to
the rows for the Marketing project screens:
• Marketing Create Issue Screen
• Marketing Edit Issue Screen
• Marketing Resolve Issue Screen
• Marketing View Issue Screen
Which screen or screens should the Approved field appear on?
Answer: The Approved field only needs to appear on the View

Issue screen. It’s not required on the Create Issue screen as the
user doesn’t need to enter it when an issue is created. Likewise,
it’s not needed on the Resolve Issue screen. And you don’t want
it on the Edit Issue screen as then any user who could edit the
issue could set the field to Yes!

iv. Click the checkbox for Marketing View Issue screen and click
Update.
d. Confirm you see the new Approved flag on the Custom fields page.
2. View a workflow scheme and workflows:

a. Navigate to the Marketing project, view the project settings and
select Summary in the sidebar.
b. Open the workflow scheme used by this project, MAR: Project
Management Workflow Scheme.
How many workflows are used in this project and what issue types
do they apply to?
Answer: Two workflows are used in the Marketing project. The MAR:
Project Management Workflow is used by the Task and Sub-task
issue types. The Content Management workflow is used by the
Document issue type.
c. View the MAR: Project Management Workflow. This is a very simple

workflow which is all that’s needed for Marketing tasks and sub-
tasks.
d. View the Content Management workflow. This is a fairly simple

workflow used for Marketing blogs.

How many projects use this Content Management workflow?
Answer: Open the workflow in edit mode. Next to the name of the
workflow, you can see that 2 projects use this workflow. If you click 2
PROJECTS, you can see that the projects are HR and Marketing.
Marketing wants approval added to the workflow but HR doesn’t.

How should we go about making the change for Marketing?
Answer: If we edit this Content Management workflow, it will affect

the HR project’s workflow which we don’t want. Instead, we should
make a copy of the Content Management workflow and edit that.
Then update the workflow scheme for the Marketing project to use
the new workflow.
3. Copy the workflow:

a. Navigate to the Workflows Jira administration page.
b. Click Copy in the row of the Content Management workflow.
c. On the Copy Workflow dialog:
i. Workflow Name: Content Management with Approval
ii. Description: Content management workflow with approval
iii. Click Copy.
d. You are now taken to the workflow editor. Note the INACTIVE
indicator. This workflow won’t become active until you add it to a
workflow scheme for a project.
Copy and edit existing workflows rather than creating workflows

from scratch.

4. Add a self-reflecting transition:
Here we add approval to the workflow to approve publication. Even though

this Content Management workflow is fairly simple, the Jira admin wants
to keep workflows as simple as possible so the approval should be
implemented without adding any new statuses. To do this, we add a self-
reflecting (looping) transition which means the transition’s starting point
and destination are the same status.
When designing a workflow, keep the workflow as simple as possible, so

consider if a transition or a status is actually needed. One way to avoid
many statuses is to use self-reflecting transitions.
Most tasks here can be done in Text or Diagram mode. These instructions
will use mainly text mode but feel free to use Diagram mode if you’re more
comfortable there.
a. In text view, on the In Review step, click Add transition.

b. Enter new transition details:
i. Transition Name: Approve publication
ii. Destination Step: In Review
iii. Transition View: leave at default of No view for transition as
we don’t need a transition screen
iv. Click Add.
c. Confirm the new transition’s starting point and destination is In

Review. In text mode:
In diagram mode, showing transition labels:

5. Configure the Approve publication transition:
The requirements are that only Content Managers should be able to

approve publication of blogs. And when a blog is approved for publication
the Approved flag should be set.
a. Add a condition restricting who can approve publication:

i. In diagram mode, select the Approve publication transition
and click Conditions.
ii. Click Add condition and add a User Is In Project Role
condition.
iii. Select the Content Managers project role, then click Add.
b. Add a post function that sets the approval flag:

i. Continuing to edit the Approve publication transition, add an
Update Issue Custom Field post function.
ii. Enter parameters:
1. Issue Custom Field: Approved
2. Custom Field Value: Yes
3. Append value: Leave unchecked
4. Click Add.
iii. Confirm the new post function is displayed.

6. Configure the Publish transition:
The requirements are that blogs should only be able to be published once
they have been approved and only Content Managers should be able to
publish.
a. Add a condition restricting execution based on Approved flag:

i. Edit the Publish transition and add a Value Field condition.
ii. Enter parameters:
1. Field: Approved
2. Condition: =
3. Value: Yes
4. Comparison Type: String
5. Click Add.
iii. Confirm the new condition is displayed.
b. Add a condition restricting who can approve publication:

i. Add a User Is In Project Role condition.
ii. Select the Content Managers project role, then click Add.
As you’re editing an inactive workflow there’s no need to publish

your changes as you’re directly editing the workflow.
7. Update the workflow scheme:
To make the new workflow active in the Marketing project we need to

update the workflow scheme for that project.
a. Navigate to the Workflow schemes Jira administration page and

edit the MAR: Project Management Workflow Scheme.
b. Click Add Workflow and select Add Existing.

c. Select your new Content Management with Approval workflow and
click Next.
d. On the Assign Issue Types to “Content Management with Approval”
dialog, check Document.
Note the alert. Currently the Document issue type is the only issue
type assigned to the old Content Management workflow. By
changing which workflow this issue type is assigned to, we’ll be
deactivating the Content Management workflow in this project.
Even though the Marketing project only uses the Task, Sub-task and
Document issue types, on this screen you see all the issue types
available on your Jira instance.
e. Click Finish and before publishing, confirm the Content

Management with Approval workflow is used by the Document
issue type in the Marketing project’s workflow scheme.
f. Publish the workflow scheme.
g. Since the statuses and issue types are the same in the old and new
workflows, all issue types and statuses can be migrated
automatically. Click Associate and then Acknowledge.
8. Verify your workflow changes:

a. Navigate to the Marketing project’s People project settings page.
Who is in the Content Managers role for this project?
Answer: Harvey Jennings is the Content Manager for this project.
b. Navigate to the Marketing project’s Issues page and view the MAR-2
issue which is in review.
Can Alana approve this issue for publication? Why or why not?
Answer: No, she cannot see the Approve publication transition

button because she’s not a Content Manager.

c. Log in as Harvey Jennings and view the MAR-2 issue.
Can Harvey approve this issue for publication? Why or why not?
Answer: Yes, he can see the Approve publication transition button

because he’s a member of the Content Manager role for the
Marketing project.
Does Harvey see the Publish transition or the Approved flag? Why or
why not?
Answer: Harvey doesn’t see the Publish transition or the Approved

flag because the issue hasn’t been approved yet.
d. Select Approve publication.
Does Harvey see the Publish transition or the Approved flag? Why or
why not?
Answer: Harvey now sees the Publish transition and the Approved
flag (set to Yes) because the issue has now been approved.
Since the issue has been approved, you no longer need to show the
Approve publication transition button. It’s a bit confusing. How
could you make this not appear once the issue has been approved?
Answer: To make the Approve publication transition not appear

once the issue has been approved, you could add a condition to the
transition. You’d use the Value Field condition and only allow
execution of the Approve publication transition if the value of the
Approved field did not equal Yes.

Exercise 2 – Adding Rejection to a Workflow
below.
High-level Requirements:
Here we continue editing the Marketing approval workflow.
1. Blog issues should be able to be rejected at any point in the workflow.

2. Only Content Managers can reject blog issues.
3. Verify the workflow by testing it as a Content Manager and a user who is
4. View the audit log.
Hints (if you need them)

1. Blog issues should be able to be rejected at any point in the workflow.
o Hint: Use a global transition. But you may need to add a new status
first.
2. Only Content Managers can reject blog issues.
o Hint: Add a condition to your new transition.
1. Create a new status:
Here we continue editing the Content Management with Approval

workflow. The next requirement is that issues should be able to be rejected
by the Content Manager at any point in the workflow. To achieve this, we’ll
create a new REJECTED status then add it to the workflow with a global
transition. Then we’ll create a condition that only Content Managers can
execute the global transition.

b. Navigate to the Statuses Jira administration page (under Issues).
c. Click Add status and enter:
i. Name: Rejected
ii. Description: The issue has been rejected
iii. Category: Done
iv. Click Add.
d. Confirm the new Rejected status is displayed in the list.

2. Add status with global transition to workflow:
a. Edit the Marketing project’s approval workflow, Content
Management with Approval.
You can add a new status in either Diagram or Text mode. In text
mode, you use Add New Step and specify both a step name and a
Linked status. Note that these can be different. However, you can
only add a status with a global transition in Diagram mode.
b. In Diagram mode, click Add status.

c. Select your new Rejected status then check Allow all statuses to
transition to this one.
d. You should now see your new Rejected status with the global
transition.
3. Restrict execution of global transition so that only members of the Content

Managers project role can execute this transition:
a. Click All in the diagram to configure the global transition.
b. Click Conditions, and then Add condition.
c. Select the User Is In Project Role condition and click Add.
d. Select Content Managers from the Project Role menu. Then click
Add.
e. Return to the workflow in diagram mode and ensure your workflow

is laid out clearly.
When you finish editing a workflow, always ensure it’s presentation

quality so users and stakeholders can clearly see what's going on.
Recall that they can view the workflow from an issue by clicking the
View Workflow link. If you ever want to disable this link for certain

users, you can edit the permission scheme and remove the users
from the View Read-Only Workflow permission.
f. Publish your draft workflow and save a backup copy if you wish.
Now your workflow is active.
4. Verify your workflow changes:

a. Open issue MAR-4 which is in the TO DO status and note if Alana
sees the Rejected transition.
b. Click the Start Draft transition.
Can Alana see the Rejected transition in either of these statuses?

Why or why not?
Answer: No, she cannot see the Rejected transition because she’s

d. Open issue MAR-7 which is in the TO DO status and note if he sees
the Rejected transition.
e. Click the Start Draft transition.
Can Harvey see the Rejected transition in either of these statuses?

Why or why not?
Answer: Yes, he can see the Rejected transition in both these

statuses because he’s a member of the Content Manager role for the
Marketing project.
Use project roles in your workflows whenever possible. This makes it

easier to share workflows between projects. Once this workflow is
complete Alana could use it in other projects that require an
approval workflow. Then whatever users are in the Content
Managers role in those projects could approve and reject issues.
f. Click the Rejected transition.
5. View the audit log:

a. Log in as Alana Grant.
b. Navigate to the Audit Log Jira administration page (under System).
c. Enter workflows in the search box. This shows all the entries in the
workflows category.
View this log to see who changed what and where. You can see
what workflows and workflow schemes were created, updated,
deleted, copied, and renamed who did so, and when they did it. It

also shows who added a workflow scheme to which project or
removed a workflow scheme from a project. This is useful if you ever
need to rollback a project’s settings.
Optional Exercise 3 – Share a Workflow

High-level instructions
on the next page.
Jira provides a way for you to share your workflows – by exporting them from
your Cloud site then importing to a Server instance or by sharing them on the
Atlassian Marketplace. You can also import workflows others have created
from the Atlassian Marketplace.
1. Export a workflow as XML:

a. Log in as the site administrator, Ryan Lee.
b. Navigate to the Workflows Jira administration page.
c. Export the TIS DEV workflow as XML.
d. Navigate to the default download location for your browser on your
local machine and view the TIS DEV workflow.xml or just TIS file.
Here you see the XML code for your workflow.
2. Export a workflow as Workflow:

a. Back on the Workflows Jira administration page, export the TIS DEV
workflow again, this time As Workflow.
b. Note the places you can use your workflow. You can import it to
another instance of Jira or share it with others on the Atlassian
Marketplace.
c. On the Add Notes page read the special instructions. Jira auto-
populates these notes for you when it discards parts of your
workflow (for example, apps (plugins), post functions, conditions,
validators).

When exporting workflows, use the Add Notes screen to add any
special configuration notes; for example, information about apps
that should be installed.
d. Export and save the file.
3. View workflows on the Atlassian Marketplace.
Congratulations on completing all the labs!
Detailed instructions
Jira provides a way for you to share your workflows – with other users at your
organization by exporting then importing to another instance or by sharing
them on the Atlassian Marketplace. You can also download workflows others
have created from the Atlassian Marketplace. You can export and import as
both XML and as workflow. We’ll cover both here.
1. Export a workflow as XML:
a. Log in as the site administrator, Ryan Lee.
b. Navigate to the Workflows Jira administration page.
c. View the TIS DEV workflow.
d. Click Export > As XML.
e. If you are prompted to save the file, click OK. It will be saved as the
file TIS DEV workflow.xml or just TIS.
f. Navigate to the default download location for your browser on your
local machine and confirm the file exists.
This is commonly in the Downloads folder. If you don't find it there

check your browser preferences.
g. Open and view the file using a text editor on your local machine.
Here you see the XML code for your workflow.

2. Export a workflow as Workflow:
a. Back on the Workflows Jira administration page, export the TIS DEV
workflow again, this time As Workflow.
b. Note the places you can use your workflow. You can import it to
another instance of Jira or share it with others on the Atlassian
Marketplace.
c. On the Add Notes page read the special instructions. Jira auto-
populates these notes for you when it discards parts of your
workflow (for example, apps (plugins), post functions, conditions,
validators).
d. Click Next.
When exporting workflows, use the Add Notes screen to add any
special configuration notes; for example, information about apps
that should be installed.
e. Export and save the file.
3. View workflows on the Atlassian Marketplace:

f. On the Workflows Jira administration page, click Import from
Marketplace.
Browse the workflows that are available to import.
Congratulations on completing all the labs!

Lab 7 Appendix
Further Reading
Reference URL
Working in http://go.atlassian.com/cloud_wftext
text mode
Building http://blogs.atlassian.com/2013/10/building-workflow-awesome
workflows
Part 1
Building http://blogs.atlassian.com/2013/10/using-workflow-awesome
workflows
Part 2
Jira Core – http://go.atlassian.com/core_cloud_wfs

Build the
workflow
you need
Best Practices
Editing You start to edit a Before editing workflows,

workflows takes workflow but things are plan your changes and think
a long time. not working correctly about all the Jira resources
because you don’t have that you’ll be using in
the resources in place you conditions, etc. This will
need for the workflow – make the actual editing of
statuses, resolutions, the workflow much faster
project roles, groups, etc. and easier.
You spend a lot Whenever there is a need Copy and customize an

of time creating for a new workflow, you existing workflow rather
workflows from build it from scratch to than creating one from
scratch. match the business scratch.
requirements of the
project.

User frustration A workflow that has 15 Try and keep your

because they separate statuses and 20 workflows as simple as
cannot transitions. possible. Keep the number
understand an of statuses and transitions
overly complex to a minimum to make
workflow them easy to use. Aim for
simple and scalable. One
way to avoid many statuses
is to use self-reflecting
transitions.
You can also use an
Approval flag instead of a
status to restrict when
issues can be transitioned in
a workflow.
Users don't know Confusing status and Ensure your status and
which workflow transition names such as transition names are
transition to use In, Out, Gone, Fixed, etc. intuitive. Don't use
next. They’re resolutions for status
confused about names.
what work is
being done.

GettingMoreJiraWorkflows CLD LW 2020-12-03-Lab

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

GettingMoreJiraWorkflows CLD LW 2020-12-03-Lab

Uploaded by

Copyright:

Available Formats

Getting More from

Getting More from Jira Workflows - Cloud Copyright © 2020 Atlassian

03 December 2020 – Cloud

Getting More from Jira Workflows - Cloud Copyright © 2020 Atlassian

There is no lab for this module.

1 Getting More from Jira Workflows - Cloud Copyright © 2020 Atlassian

Exercise 1 – Exploring Workflow

1. View the Teams in Space workflow:

b. If you see a prompt to select navigation, choose Use improved

This is a representation of the project’s workflow and you can see

3 Getting More from Jira Workflows - Cloud Copyright © 2020 Atlassian

Answer: No, he isn’t. The workflow in Jira Cloud needs to be changed

What transitions run between IN PROGRESS and INSPECTION?

Answer: The Ready for review transition runs from IN PROGRESS to

d. Exit the workflow view.

2. View the project’s board configuration:

Answer: The project admin needs to be a Board administrator. You

b. View the board’s Columns Page.

4 Getting More from Jira Workflows - Cloud Copyright © 2020 Atlassian

Answer: No, he cannot add statuses to this board because this

3. Rename a workflow status:

The company wants to rename one of their statuses, Inspection, to In

The categories – To Do, In Progress, and Done – help you identify

5 Getting More from Jira Workflows - Cloud Copyright © 2020 Atlassian

c. View the Inspection status.

What should you do before renaming a status?

Answer: Before renaming a status, always check to see if it’s in use

d. Rename the Inspection status to In Code Review with the

Note that you’re now editing a draft (inactive) version of this

4. Configure the project’s board:

What needs to be done now?

Answer: You need to rename the column heading to match the

6 Getting More from Jira Workflows - Cloud Copyright © 2020 Atlassian

b. Configure the board and change the Inspection column heading to In

e. Close this workflow window.

To start the next exercise, go to page 13.

b. If you see a prompt to select navigation, choose Use improved

This is a representation of the project’s workflow and you can see

7 Getting More from Jira Workflows - Cloud Copyright © 2020 Atlassian

Is the project admin able to edit the workflow?

Answer: No, he isn’t. The workflow in Jira Cloud needs to be changed

What transitions run between IN PROGRESS and INSPECTION?

8 Getting More from Jira Workflows - Cloud Copyright © 2020 Atlassian

g. Click Close to exit the workflow view.

2. View the project’s board configuration:

View the General page.

Answer: The project admin needs to be a Board administrator. You

9 Getting More from Jira Workflows - Cloud Copyright © 2020 Atlassian

b. Click Columns in the sidebar.

Answer: No, he cannot add statuses to this board because this

3. Rename a workflow status:

The company wants to rename one of their statuses, Inspection, to In Code

10 Getting More from Jira Workflows - Cloud Copyright © 2020 Atlassian

The categories – To Do, In Progress, and Done – help you identify

d. Scroll down and view the Inspection status.

What should you do before renaming a status?

Answer: Before renaming a status, always check to see if it’s in use

e. Click Edit for the Inspection status and enter:

f. Confirm the status has been changed on the Statuses page.

11 Getting More from Jira Workflows - Cloud Copyright © 2020 Atlassian

Note that you’re now editing a draft (inactive) version of this

k. Click Edit on the Inspection step.

o. Save a backup copy if you wish, then click Publish.