1 - JIRA Administration Part 1

2 - JIRA Administration Part 1

3 - JIRA Administration Part 1
 You are here to learn the basics of JIRA Administration!

4 - JIRA Administration Part 1

 You should know the basics of using the JIRA application(s) you have – JIRA Software, JIRA
Service Desk, and/or JIRA Core.

5 - JIRA Administration Part 1

 This is the location of Atlassian’s headquarters in Sydney, Australia.

6 - JIRA Administration Part 1

 Schedule for the course.

7 - JIRA Administration Part 1

 Are you prepared for this course?
What is your job role?
What do you expect from this course?

8 - JIRA Administration Part 1

 We encourage you to actively participate. It makes it more fun and people learn more if
attendees share their insights and thoughts with the class!

9 - JIRA Administration Part 1

 Take this opportunity to ask questions.

10 - JIRA Administration Part 1

11 - JIRA Administration Part 1
 This is the location of the Atlassian office in San Francisco, USA.

12 - JIRA Administration Part 1

13 - JIRA Administration Part 1
 You own the experience of using JIRA – you are the JIRA Evangelist.
It’s up to you to make JIRA easy to use.
You need to ensure your company gets value from JIRA.
You build the JIRA instance, you release it to users, then they start using it. Then it’s up to you
to get user feedback and update JIRA. Take the time to listen to the users and stakeholders,
understand their pain points, so that you can learn from their experience. e.g. users complain
of too many fields or don’t understand what a field means – make changes. Use the JIRA Issue
Collector! JIRA needs to constantly evolve as it adapts to your business.
See https://www.youtube.com/watch?v=H-s_Dd2geGQ.

14 - JIRA Administration Part 1

 JIRA is an issue tracking system that has been primarily used within the software development
field. Many, over the past few years, have found that JIRA is flexible enough to support other
areas of focus outside of software development. Many non software development project
teams use JIRA for tracking issues as well as Finance teams and more. These are the three
main audiences for the JIRA Platform.

15 - JIRA Administration Part 1

 With JIRA 7 there are three applications that make up the JIRA Platform. These applications
match the three main audiences. Each JIRA application comes complete with a specific set of
features and functions, which tailors the experience delivered to its users.
JIRA Software is designed for agile teams whose focus is software development. JIRA
Software enables you to plan projects, manage dependencies and track team progress.
JIRA Service Desk is designed for IT and service teams to implement service desks quickly
and to manage incidents, problems, changes, and service requests.
JIRA Core is designed for business teams, whose goals are to keep their teams organized by
planning, tracking, and reporting on their business projects. It’s a lightweight version of JIRA
Software, stripping away all unnecessary features for Business teams e.g. sprint planning.
Examples of its use:
•  HR use it to manage candidate tracking and employee onboarding.
•  Finance use it to manage tracking and procurement processes.
•  Marketing use it to manage review cycles and marketing collateral.

16 - JIRA Administration Part 1

 JIRA has three deployment options – Cloud, Server and Data Center. This course focuses on
JIRA Server.
Cloud – Aimed at small businesses and teams with no system administrators on staff or
businesses that want minimal overhead in system administration. They do not want to maintain
servers, software upgrades, and other things that an IT system administrator, server
administrators and a host of others must take care of. There is a System Administrator in the
Cloud but it’s only accessible by Support. All functions performed by the JIRA System
administrator in JIRA server applications are restricted in JIRA Cloud applications. (For a list,
see https://confluence.atlassian.com/display/AdminJIRAServer070/Restricted+functions+in
+JIRA+Cloud+applications.) The Cloud option has a monthly or annual subscription.
Server - Runs on your hardware behind your firewall. JIRA Server is aimed at large businesses
and teams that plan to integrate JIRA with their own internal systems. Also businesses who do
not want any part of their data in the cloud. And businesses and teams that simply want full
control over everything. It has a perpetual license.
Data Center – Designed for high availability and performance at scale when hosting Atlassian
applications in your own data center. It’s for organizations that have the need for scale,
specifically when they have many concurrent users. It has an annual term license.
For the pros and cons of Cloud vs. Server see see https://confluence.atlassian.com/display/
CLOUDKB/Pros+and+Cons+of+Cloud+vs.+Server and http://adminsofatlassian.com/jira-
cloud-vs-jira-server.

17 - JIRA Administration Part 1

 On the Versions & licenses page you can:
•  See what JIRA applications are installed
•  Change the type of license
•  Upgrade your user tier to accommodate new users
•  Add a new license when your old license has expired
•  Add a new license for a newly installed application
•  View details of your licenses – licensed user count, maintenance expiry, license type, etc.
If you exceed the licensed user count allowed by your JIRA application’s license, your
users won’t be able to create issues.
You may want to purchase a full license when your evaluation license expires.
Warning - If you exceed your user count, either upgrade to a larger license or reduce your
existing user count. If you’re near the maximum users for your license, you’ll see a banner
prompting you to upgrade. You can click the Upgrade button in the banner to be redirected to
the Atlassian order form.
Number of licensed users - Every user in JIRA will have access to an application based on
their membership in groups. (We’ll cover groups and application access in the next module.) A
user may have access to all the applications, or only one application. If a user has access to an
application, they will count as one licensed user for that application. For example, if a user
belongs to a group for JIRA Software and a group for JIRA Service Desk, they will count as a
licensed user for both JIRA Software and JIRA Service Desk.

18 - JIRA Administration Part 1

 All the tasks listed here are covered in the rest of this module.
Branding your look and feel includes customizing the default dashboard and the Application
Navigator.
Global permissions and project roles are also very important tasks to configure your instance.
These will be covered in later modules.

19 - JIRA Administration Part 1

 You can easily integrate other Atlassian products with JIRA. This is done from the Applications
administration section under INTEGRATIONS.
You can also integrate with collaboration tools such as Confluence and HipChat. Confluence
gives your teams the ability to share, discuss and work with JIRA application issues in
Confluence, and create knowledge articles for your service desk customers. Integrating JIRA
applications and HipChat gives you and your teams the following collaboration power:
•  Get notifications in your HipChat rooms when a customer updates a service desk
request, or a developer comments on an issue.
•  Create a dedicated HipChat room from the issue you're working on and want to discuss
with your team.
•  Preview JIRA issues and service desk requests directly in HipChat when someone on
your team mentions them.
See https://confluence.atlassian.com/display/AdminJIRAServer070/Integrating+with
+collaboration+tools.
You can integrate with Development Tools such as Bamboo, Bitbucket, FishEye/Crucibe, and
Github. Connecting JIRA Software to compatible development tools provides your team with
a range of functionality and information related to your development work.
See https://confluence.atlassian.com/display/AdminJIRAServer070/Integrating+with
+development+tools.
In this course we’ll cover integrating JIRA with Confluence – see next slide.



20 - JIRA Administration Part 1
 Confluence and JIRA are like bacon and eggs or coffee and cake. Separately, they're great,
but together, they're amazing! Linking these applications together allows your users to display
and create JIRA issues and more from Confluence. It also allows JIRA Software users to link
and create Confluence pages from epics and sprints.
Typically JIRA and Confluence are installed together. To link the applications, you just need to
know the Confluence URL
Then you link the applications through the INTEGRATIONS – Applications links page in
Administration. You supply the Confluence URL. A link to Confluence will automatically be
added to the Application Navigator.
Application Links (sometimes called "AppLinks") is a bundled plugin that allows you to link
Atlassian applications to each other. Linking two applications allows you to share information
and access one application's functions and resources from within the other. See https://
confluence.atlassian.com/display/AdminJIRAServer070/Using+AppLinks+to+link+to+other
+applications
The application navigator is the icon (three horizontal bars) in the top left of the JIRA header
that displays a menu of links to other applications. It is only displayed to users if there is more
than one link. You can add custom links in the application navigator, to make it easier for users
to navigate to frequently used information. By adding a link to Confluence here, users can
quickly and easily move between the applications.

21 - JIRA Administration Part 1

 You can customize the links that appear in the application navigator, as well as making certain
links only visible for specific users. This lets users quickly access other applications.
Linked applications are added automatically. You can add your own links for users by giving
the name and URL. You can also restrict the links to groups of users.

22 - JIRA Administration Part 1

 An add-on is an installable component that supplements or enhances the functionality of JIRA
in some way. For example, the JIRA Calendar Plugin is an add-on that shows the due dates for
issues and versions in calendar format. Other add-ons are available for connecting JIRA to
Bamboo, developing for JIRA, and accessing Atlassian support from JIRA.
JIRA comes with many pre-installed add-ons (called system add-ons). You can install more
add-ons, either by downloading an add-on from the Atlassian Marketplace, or by uploading an
add-on from your file system. This means that you can install add-ons that you’ve developed
yourself. The add-ons available in the Atlassian Marketplace are from Atlassian and third-party
vendors. There are over 2,000 add-ons available in the Atlassian Marketplace.
Governance is important. If you install an add on, users start using it and get used to the extra
functionality. If you remove it, you may have unhappy users. For example, you may install an
add-on for extended JQL functionality. Then you disable it because system has grown, more
people are using it and there’s a performance hit. But users have gotten used to the JQL
extensions and now all custom JQL will be invalid. Users aren’t happy. The important point is
that before you install an add-on, ensure there’s a business requirement for it, don’t just install
any add-on. Do your due diligence before installing.
See https://confluence.atlassian.com/display/AdminJIRAServer070/Managing+add-ons/.
The terms 'add-on' and 'plugin’ are often used interchangeably, there is a difference. A plugin
is a type of add-on that can be installed into an Atlassian host application. Plugins are what
developers create with the Atlassian SDK.

23 - JIRA Administration Part 1

 On the Look and Feel page you configure your branding. For example you can upload or link to
your company’s logo. The color scheme will be updated automatically to match your logo. Or
you can set the colors individually.
The Site Title is the name of the instance e.g. JIRA and will appear to the right of the logo, if
enabled.
You can also upload or link to your own Favicon which typically appears to the left of your
browser’s URL field and on browser tabs displaying a page on your JIRA site. It must be a
png.
Date/Time format allows you to customize the way dates and times are presented to users in
JIRA.
See https://confluence.atlassian.com/display/AdminJIRAServer070/Configuring+the+look+and
+feel+of+your+JIRA+applications.
Here you see a JIRA instance that has been customized with a a favicon and a new logo (thus
changing the color scheme). The Site Title is also enabled.
Go to design.atlassian.com for principles, guidelines and assets for designing and building
awesome Atlassian experiences.

24 - JIRA Administration Part 1

 The default dashboard is the screen that all JIRA users see the first time they log in. Any users
who have not added any dashboard pages as favorites also see the default dashboard.
JIRA Administrators can configure the default dashboard by:
1.  Adding gadgets to the dashboard. Gadgets are the information boxes on the dashboard.
JIRA comes pre-configured with a set of standard dashboard gadgets.
2.  Re-ordering gadgets on the dashboard or switching them between the left and right
columns.
3.  Configuring the layout of the dashboard (e.g. number of columns) can also be configured.
And some gadgets can be configured. All changes made to the default dashboard will also
change the dashboards of all users currently using the default. Note that gadgets that users do
not have permissions to see will not be displayed to them. For example, if the 'Administration'
gadget exists in the default dashboard configuration, it will not be visible to non-administrator
users.

25 - JIRA Administration Part 1

26 - JIRA Administration Part 1
 Answers:
1. b
2. c

27 - JIRA Administration Part 1

28 - JIRA Administration Part 1
 Answers:
1. c
2. b (Only for JIRA Software and JIRA Core, not JIRA Service Desk.)

29 - JIRA Administration Part 1

 You can customize the links that appear in the application navigator in JIRA, as well as making
certain links only visible for specific users. This lets users quickly access other frequently used
applications.
Add-ons – governance is important. If you install an add on, users start using it and get used
to the extra functionality then if you remove it, you may have unhappy users. E.g. Install add-
on for extended JQL functionality then disable disable it because system has grown, more
people are using it and there’s a performance hit. But users have gotten used to the JQL
extensions and now all custom JQL will be invalid. Users aren’t happy. The important point is
that before you install an add-on, ensure there’s a business requirement for it, don’t just install
any add-on. Do your due diligence before installing.

30 - JIRA Administration Part 1

 Teams in Space is a fictional company that specializes in space travel for teams. This is the
case study we will use throughout the course. The company is distributed across the universe.
The company has just installed JIRA to allow their distributed teams to run more efficiently,
where tasks are visible, shared and easy to access.
You are the JIRA Administrator. The JIRA applications (Software, Service Desk, and Core) have
just been installed. Now you need to set up and configure the instance so their teams can start
using it. You have one day so let's get started!

31 - JIRA Administration Part 1

32 - JIRA Administration Part 1
 The Lab Workbook contains both High Level Instructions and Detailed Instructions. Use the
High Level instructions for less guidance if you feel like a challenge. Use the Detailed
Instructions for step by step instructions.

33 - JIRA Administration Part 1

 An opportunity to ask questions.

34 - JIRA Administration Part 1

 Most user-visible pages in JIRA are internationalized and can be viewed in Chinese, Czech,
Danish, English, French, German, Italian, Norwegian, Polish, Portugese (Brazilian), Russian,
Japanese, Slovak, and Spanish. More are in development. When you install JIRA a number of
languages are installed and you can choose default then. Additional language packs can be
installed through Add-ons.
Individual users can override the default language by managing their user profile.
The default installed languages are English (UK), English (US), French, German, Japanese, and
Spanish.
You can change the default language for JIRA on the General configuration administration
page (under System).
For a list of all the languages available, see translations.atlassian.com.

35 - JIRA Administration Part 1

 JIRA's time tracking feature enables users to record the time they spend working on issues. An
Administrator can configure time tracking settings and, can disable time tracking altogether.
Configure time tracking settings by editing the following fields:
•  'Hours per day' — enter a suitable value (e.g. 8). You can enter fractions if you wish.
•  'Days per week' — enter a suitable value (e.g. 5). You can enter fractions if you wish.
•  'Time format' — select pretty/days/hours. This will determine the format of the 'Time
Spent' field when an issue is displayed.
•  'Default Unit' — select minutes/hours/days/weeks. This will be applied whenever your
users log work on an issue without specifying a unit.
•  'Legacy Mode' — select this checkbox if you prefer to use JIRA's time tracking features
as they operated prior to JIRA version 4.2.
•  'Copy Comment To Work Description' — select this checkbox to ensure that any content
entered into a Comment field while logging work as part of an issue operation, is also
copied across to the Work Description. When 'Copy
•  If ‘Comment To Work Description' is enabled, your user's work log entries will be visible
only to members of the project role or group selected in the padlock icon drop-down on
their issue operation screen. If 'Copy Comment To Work Description' is disabled, your
user's work log entries will be visible to anyone by default.
See https://confluence.atlassian.com/display/AdminJIRAServer070/Configuring+time
+tracking.

36 - JIRA Administration Part 1

 The application log file, atlassian-jira.log is written to the log subdirectory of your JIRA
application home directory. Find the location of both your JIRA home directory and the
location of the log file in System > System info, File Paths.
Security-related information e.g. login, logout, session creation/destruction, security denials is
stored in atlassian-jira-security.log.
There are five logging levels available in log4j: 'DEBUG', 'INFO', 'WARN', 'ERROR' and
'FATAL'. Each logging level provides more logging information that the level before it. 'DEBUG'
provides the most verbose logging and 'FATAL' provides the least verbose logging. The
default level is WARN, meaning warnings and errors are displayed. Sometimes it is useful to
adjust this level to see more detail. (warning) Please be aware: the 'DEBUG' setting may cause
user passwords to be logged.
The default logging levels can be changed either:
•  temporarily — your change to the logging level will not persist after you next restart JIRA,
or
•  permanently — your change to the logging level will persist, even after you restart JIRA.
For example, when troubleshooting, you might temporarily change the logging level from
'WARNING' to 'INFO' so as to get a more detailed error message or a stack trace. If you are
unsure of which logging categories to adjust, the most helpful information generally comes
from the log4j.rootLogger category and the log4j<category>.com.atlassian categories.
NOTES CONTINUED ON NEXT SLIDE

37 - JIRA Administration Part 1

 NOTES CONTINUED FROM PREVIOUS SLIDE
You can also set retention for the log files themselves.
For more information on logging, including editing the logging settings in the log4j.properties
file, see https://confluence.atlassian.com/display/AdminJIRAServer070/Logging+and+profiling.

38 - JIRA Administration Part 1

 We won’t go into troubleshooting practices here as it’s beyond the scope of this course. But
two recommendations we will make at this level are to talk to an experienced System
Administrator at your site and also to use the Support Tools within JIRA to create a Support
zip file to send to Atlassian Support.
The Support Tools plugin has been developed by Atlassian Support to help you:
•  Keep an eye the health of your instance, and alert you problems with your configuration
•  Log a Support Request
•  Create a Support Zip, which contains configuration and diagnostic information for
Atlassian Support. This file is saved in <JIRA_HOME/export/
JIRA_support_<timestamp>.zip.
•  Scan your instance logs against our knowledge, to help you diagnose and troubleshoot
known issues
•  Schedule automatic log scans and summaries
More information on the Support Tools can be found at https://confluence.atlassian.com/
support/support-tools-plugin-790796813.html.

39 - JIRA Administration Part 1

 JIRA Auditing:
•  Tracks key activities in JIRA applications
•  Records configuration changes that can impact users and projects
•  Is a handy tool to diagnose problems
See https://confluence.atlassian.com/display/AdminJIRAServer070/Auditing+in+JIRA
+applications.
You can change the retention period from the default of unlimited. If you modify the audit log
retention period, ensure you follow your company’s retention policies!
You can also configure the audit log to not include events triggered from your external
repository.
View the audit log in System > Audit Log.

40 - JIRA Administration Part 1

 Notifications allow you to send emails to users when particular events occur. For example
when you create a new user you can select to notify them by email or even invite them by
email. You can also set up notifications for other events such as issue created, updated,
resolved, etc. See https://confluence.atlassian.com/display/AdminJIRAServer070/Creating+a
+notification+scheme for a list of all the events that can trigger notifications. Be careful how
many notifications you enable: your users may feel inundated if they receive too many JIRA
notifications. We’ll discuss how to edit notifications later in the course.
For JIRA to send email notifications about various events, you need to configure an SMTP
server in JIRA. Set up the outgoing server through System > Outgoing Mail.
See https://confluence.atlassian.com/display/AdminJIRAServer070/Configuring+JIRA's+SMTP
+mail+server+to+send+notifications for details.

41 - JIRA Administration Part 1

 JIRA can operate in two modes:
•  Private – only administrators can create new users if the JIRA Internal Directory is used.
However if you use an external user repository such as LDAP and JIRA set to read only then
then users will be created in the external user directory by the user directory manager
(which will probably be a different person than the JIRA Administrator). We’ll cover user
directories in the next module.
•  Public – any user can sign up and post issues. Administrators don’t need to be involved.
For some organizations it is appropriate to enable public signup, which allows users to
create their own accounts. If these users create accounts that gives them access to JIRA
Core or JIRA Software, these accounts will consume a license for these applications. If
public signup is switched on for JIRA Service Desk, and customers create their own
accounts, these accounts do not consume a license. Think carefully before enabling public
signup - consider your license limits. New users are automatically added to the default
application group so be aware of what they’ll be able to do.

If you enable public signup through the General Configuration page it applies only to JIRA
Software and JIRA Core. If you have both of these installed, the user will be added to the
default group for JIRA Software. If you have only JIRA Core installed, the user will be added
to the default group for JIRA Core. If you enable public signup for Service Desk through the
Service Desk Configuration page, the user will be added to the default group for Service

NOTES CONTINUED ON NEXT SLIDE

42 - JIRA Administration Part 1

 NOTES CONTINUED FROM PREVIOUS SLIDE
Desk. We’ll cover default groups in the next module.
For security reasons, even if you enable signup, it is still necessary for users to have the
appropriate project permissions before they can see or create issues. We’ll cover project
permissions later in the course
See https://confluence.atlassian.com/display/AdminJIRAServer070/Enabling+public+signup
+and+CAPTCHA.
It’s also possible to allow people anonymous access to a project where they could browse and
search for issues or even create issues without logging in. That is a project permission issue.
We won’t cover that here. But generally we recommend that if you allow anonymous access
you limit it to read-only activities such as Browse. If you allow them to create issues, anyone
can do this, and the changes are not logged because JIRA doesn’t know who the user is.

43 - JIRA Administration Part 1

 There are risks in allowing people to sign up for accounts in a publically available system. If
you put a system that allows self-signup onto the internet (accessible from outside your
organization's firewall), it becomes a target for automated spam systems (‘bots) to subvert it
for “Spam” or worse. In this case you may want to enable CAPTCHA. When CAPTCHA is
enabled, visitors will need to recognize a distorted picture of a word (see example below), and
must type the word into a text field. This is easy for humans to do, but very difficult for
computers.

44 - JIRA Administration Part 1

45 - JIRA Administration Part 1
 Answers:
1. b
2. b (Only for JIRA Software and JIRA Core, not JIRA Service Desk.)

46 - JIRA Administration Part 1

47 - JIRA Administration Part 1
48 - JIRA Administration Part 1
 A chance to give feedback about the lab. What did you find interesting? Did you get stuck?
What did you learn?

49 - JIRA Administration Part 1

 An opportunity to ask questions.

50 - JIRA Administration Part 1

51 - JIRA Administration Part 1
 This is the location of the Atlassian offices in Amsterdam, Netherlands.

52 - JIRA Administration Part 1

53 - JIRA Administration Part 1
 A user directory provides persistent storage for information about users and groups. User
information includes the person's full name, username, password, email address and other
personal information. Group information includes the name of the group, the users that belong
to the group, and possibly groups that belong to other groups.

54 - JIRA Administration Part 1

 You can add the following types of directory servers and directory managers:
•  JIRA's internal directory.
•  Microsoft Active Directory.
•  An LDAP directory for delegated authentication. A wide range of LDAP providers are
supported such as Active Directory or OpenLDAP. Microsoft Active Directory is the most
frequently used. An LDAP directory is a collection of data about users and groups. LDAP
(Lightweight Directory Access Protocol) is an Internet protocol that web applications can
use to look up information about those users and groups from the LDAP server. You can
connect your JIRA application to an LDAP directory for authentication, user and group
management. Connecting to an LDAP directory server is useful if your users and groups
are stored in a corporate directory.
•  Atlassian Crowd - Groups are managed fully (unless they themselves sit on top of LDAP).
Can collate multiple directories.
•  Another JIRA server.
There are many combinations of where user data may come from. For example, you could use
LDAP for your Corporate directory, Crowd for single sign on (SSO) and JIRA internal for
temporary guest users.
Note: Crowd is not covered in this course. Crowd is the only supported SSO right now. You
can use other SSO but Atlassian doesn’t support it.

55 - JIRA Administration Part 1

 The JIRA Internal Directory stores user and group information in the JIRA database. It is
enabled by default at installation.
When you create the first administrator during the setup procedure, that administrator’s
username and other details are stored in the internal directory.
You should maintain at least one JIRA System Administrator in the JIRA Internal Directory.
Even if your primary login is through an external directory (LDAP, Crowd, Active Directory,
etc.), this strategy prevents a lock out in the event something fails with the external directory. It
also enables troubleshooting.

56 - JIRA Administration Part 1

 When configuring the directory, you can choose to make it read only, read only with local
groups, or read/write. The purpose of this option is to identify whether changes you make in
JIRA can cause updates in the external directory.
Here we see a diagram for Read Only (Read/Write and Read Only with Local Groups are
covered on the next slides). If you choose Read Only, JIRA copies users and groups from the
LDAP directory to the LDAP cache stored in the JIRA database. But JIRA only reads from your
LDAP directory, it is not allowed to change it. LDAP users, groups and group memberships
can only be modified via your LDAP Directory server. You cannot modify them from JIRA
Administration. This works well in environments where all identity management (groups
included) is handled externally. A periodic synchronization task will run to update the JIRA
database LDAP cache with any changes made in the external directory. More on
synchronization soon.
The JIRA database does not store/cache user passwords for external user directories. All
authentication happens via calls to the external directory.

57 - JIRA Administration Part 1

 If you choose Read/Write for the LDAP user directory, JIRA copies users and groups from the
LDAP directory to the LDAP cache stored in the JIRA database. But any changes made to user
and group information in JIRA will also update the external LDAP directory.
This is rarely used. Usually the JIRA Administrator and the LDAP Administrator are different
people. When LDAP is set up for many organizations this is the single source of truth and
should not be updated from JIRA.

58 - JIRA Administration Part 1

 Using Read Only, With Local Groups for your LDAP user directory is similar to Read Only, with
one additional feature: you can add LDAP users to local groups created in the JIRA Internal
Directory. You will go through this scenario in the lab.
See https://confluence.atlassian.com/adminjiraserver070/diagrams-of-possible-configurations-
for-user-management-749382799.html.
There are two other configurations with LDAP that we will not cover here:
•  JIRA connecting to LDAP directory for authentication only.
•  JIRA connecting to an LDAP directory for authentication only, with each user copied to
the internal directory when they first log in to JIRA.

59 - JIRA Administration Part 1

 When you connect a new external user directory to the application, a synchronization task will
start running in the background to copy all the required users, groups and membership
information from the external directory to the LDAP cache in the application database. So for
example, if you have a Marketing group with users in LDAP when you create an LDAP user
directory, a Marketing group with the same users will be cached in JIRA. External directories
are cached in JIRA to aid performance. The caches are held in the application database. When
caching information from an external directory, the JIRA database does not store user
passwords for external user directories. All authentication happens via calls to the external
directory.
If the external directory permissions are set to read/write: Whenever an update is made to the
users, groups or membership information via the application, the update will also be applied to
the cache and the external directory immediately.
A synchronization task runs to update the database with any changes made to the external
LDAP directory. Default synchronization/polling interval is 1 hour. You can also manually
synchronise. Sometimes you make changes to the directory and you want to synchronize
immediately rather than wait for them to be picked up by the next scheduled directory
synchronization. You can tune the interval and the length you choose depends on:
•  The length of time you can tolerate stale data.
•  The amount of load you want to put on the application and the directory server.
NOTES CONTINUED ON NEXT SLIDE



60 - JIRA
Administration Part 1


 NOTES CONTINUED FROM PREVIOUS SLIDE
•  The size of your user base.
•  If you synchronize more frequently, then your data will be more up to date. The
downside of synchronizing more frequently is that you may overload your server with

requests.
If you are not sure what to do start with the default and reduce the value incrementally. You

will need to experiment with your setup.
For recommendations on the optimal number of users and groups in your LDAP directory so
as not to affect performance during LDAP synchronization see https://
confluence.atlassian.com/adminjiraserver070/user-management-limitations-and-
recommendations-749382815.html.

61 - JIRA Administration Part 1

 The order of the directories is the order in which they will be searched for user and group
information and for authentication.
The order of user directories in JIRA is important because it identifies which account "wins"
when there is a conflict. For example, if you had an internal JIRA directory user ”Niko" and an
LDAP Directory user ”Niko", and he had a different password in each directory. When Niko
logs in, the order of directories would determine which password he needed to authenticate.
The one listed first is the one Niko would need to log in as.
Tip: Users should only exist in a single directory. Avoid duplicate usernames across
directories!
Also, changes to users and groups will be made only in the first directory where the application
has permission to make changes.

62 - JIRA Administration Part 1

 You can enable or disable a directory at any time. If you disable a directory, your configuration
details will remain but the application will not recognize the users and groups in that directory.
You have to disable a directory before you can remove it. Removing a directory will remove the
details from the JIRA application database.
You can’t disable or remove the directory the Administrator belongs to.

63 - JIRA Administration Part 1

64 - JIRA Administration Part 1
65 - JIRA Administration Part 1
 Answers:
1.  True
2.  b

66 - JIRA Administration Part 1

67 - JIRA Administration Part 1
 Answers:
1.  c (Whichever is listed first.)
2.  a (Always store the admin user in the internal directory.)

68 - JIRA Administration Part 1

 User Directory Best Practices.
The recommended way to edit directory configurations is to log in as an internal user when
making changes to external directory configuration.
You should maintain at least one user that's both in the JIRA Internal Directory and is a JIRA
System Administrator. Even if your primary login is through an external directory (LDAP,
Crowd, Active Directory, etc.), this strategy prevents a lock out in the event something fails
with the external directory. We recommend that you keep either an administrator or system
administrator user active in your internal directory for troubleshooting problems with your user
directories.
You cannot edit, disable or remove the directory your user (i.e. you the Administrator), belongs
to. This precaution is designed to prevent administrators from locking themselves out of the
application by changing the directory configuration in a way that prevents them logging in or
removes their administration permissions.
We recommend that users only exist in a single directory. Avoid duplicate usernames across
directories!

69 - JIRA Administration Part 1

 You need to add users to JIRA. The one exception is the Admin user who is created when you
install JIRA.
Users can be added by creating an external user repository in JIRA such as LDAP, by the
administrator, or by invitation (we’ll discuss this later in this module.)

70 - JIRA Administration Part 1

 A JIRA group is a convenient way to manage a collection of users. Users can belong to many
groups.
Groups are:
•  Used throughout JIRA to manage users (e.g. provide access to applications)
•  Granted global permissions (discussed in next module)
•  Used in project permission schemes, email notification schemes, issue security levels, and
workflow conditions.
Groups can also be given access to issue filters and dashboards, and belong to project roles.
We will cover these later in the course.

71 - JIRA Administration Part 1

 The default application groups are jira-software-users for JIRA Software, jira-core-users for
JIRA Core, and jira-servicedesk-users for JIRA Service Desk. When you install your first JIRA
application (Software, Service Desk, Core) and license it, JIRA will create two user groups, and
add the JIRA administrator, to both of them – jira-administrators group and the group
corresponding to the application you installed. For example, if you installed JIRA Software then
the groups created are jira-administrators and jira-software-users. The second group is also
assigned as the default group for any new users created.
If you install and license further applications, JIRA will create a default group for that
application, but the JIRA Administrator will not be added to this group automatically.
See https://confluence.atlassian.com/display/AdminJIRAServer070/Managing+groups.

72 - JIRA Administration Part 1

 Your organization may be happy for Administrators to see and do everything, to be all
powerful. This makes it easy for them to test problems as they can do anything.
Or your organization may want to stop Admins from seeing the actual content as an
Administrator to prevent them from making a mistake and modifying/deleting content (i.e.
issues/tasks.) The point is to avoid mistakes. If this is a concern then the Administrators could
also have a personal account for JIRA. This way they could see content and test user access.
However that would use up another license.
It all depends on your organization and your policies.
If the JIRA Administrator does need access to all application data and functionality then the
jira-administrator’s group needs to be added to all JIRA applications’ default groups.
Note that there is no way to actually lock a JIRA Administrator out from accessing applications
as they have the power to add their group to any application!

73 - JIRA Administration Part 1

 In order for a user to log in and access a JIRA application, they must have application access.
Application access is obtained by being a member of a group assigned to a JIRA application.
When you create a new user, you specify which JIRA application(s) they’ll be using. The user
will automatically be added to the default group(s) associated with application(s). By default
these are jira-software-users for JIRA Software, jira-core-users for JIRA Core, and jira-
servicedesk-users for JIRA Service Desk. In this example, JIRA Core has been installed and
JIRA has automatically created the jira-core-users group. You create the user Amit and select
JIRA Core for the application they should have access to. JIRA will automatically add Amit to
the default application for Core, jira-core-users.
You can set the pre-selected default application(s) for new manually created or invited users (in
Set defaults for new users on Application access page).
If you have more than one JIRA application, it's possible to select which applications new
users will automatically be assigned to. When you create a user, the applications you select as
defaults will be pre-selected, however it's possible to change this while creating the user. If
you allow users to sign up via email, via public signup, or through a mail handler, they will be
given access to the applications you select.

74 - JIRA Administration Part 1

 We map groups to applications, rather than granting users access to applications directly, in
order to make administration at scale easier. When you have thousands of users in an LDAP
server, you only want to work at the group level.
At the same time, default groups make it easy to give someone access to an application
without having to understand the groups.
In an ideal world, you would only need one default group for each application. You have the
capability to have multiple default groups to support migration from older versions of JIRA.
If you’re using an external user repository such as LDAP when that user repository is created,
JIRA will import all the users and groups (as well as group memberships). You would either
need to add those groups to the default groups for application access or assign the right
permissions to the LDAP groups. We’ll cover this more later in the module and also in the lab.

75 - JIRA Administration Part 1

 On the Application access page, you control which groups have access to which applications.
The default groups are automatically set up for each application.
Here you can add more groups to a JIRA application, and all members of those groups will
have access to that JIRA application. If a user is a member of more than one of those groups,
they will only consume one user on your JIRA application license.
You can also set more than one default group for an application. This means that if you create
a user and specify an application with multiple default groups, the user will be added to all of
those groups.
Also, you may assign the same group to several applications. You may wish to do this to
ensure members of this group always have full application access. For example, you may have
users who require full access to all your applications. You could create a separate group for
them, and add this group to each application. Care should be taken when assigning a group to
multiple applications, as the group members will consume a license for each application. The
only exception is JIRA Core , a user with access to any other application automatically has
access to JIRA Core , so they will not consume a license for JIRA Core if they belong to a
group associated with another application.

76 - JIRA Administration Part 1

 When you have multiple applications installed, by default, all users will be able to view all
projects (unless there are specific project permissions set up that prohibit this, we’ll cover
these later). This means a JIRA Core user will be able to see all JIRA Software and JIRA
Service Desk projects. However, as they are not licensed for these applications, they will not
be able to see any features or functions that are specific to that application. For example, a
JIRA Core user viewing a JIRA Software project would be able to see the project and its
issues, but would not be able to see any JIRA Software specific features, like Agile boards,
development information, or release information. These features can only be viewed by a JIRA
Software user.
It's important to note that JIRA Core does not have any specific features or functions that
cannot be viewed and/or acted-on by other users. This means that if you are a JIRA Software
or JIRA Service Desk user, you can already view and work on a JIRA Core project. You do not
need to have specific application access for JIRA Core, and therefore do not need to consume
a license. View the JIRA applications and project types overview page for more information on
what licensed users can and cannot view and action on projects from other applications. See
https://confluence.atlassian.com/display/AdminJIRAServer070/JIRA+applications+and+project
+types+overview.

77 - JIRA Administration Part 1

 When you create an LDAP user directory, all LDAP users and groups are automatically
synchronized to the JIRA LDAP cache in the JIRA internal database. But what about
membership in the application default groups (which reside in the JIRA internal directory)? You
can specify one or more JIRA groups in the ‘Default Group Memberships’ setting when you
create the LDAP user repository. This means all LDAP users will automatically be added to
these groups. For example if you have JIRA Software installed. When you create your LDAP
user repository you enter jira-software-users in Default Group Memberships. So all LDAP users
will automatically be added to jira-software-users and will have access to JIRA Software.
It gets more complicated when you have multiple JIRA applications installed. Whatever
applications you specify in Default Group Memberships, all LDAP users will be added to all the
groups. So if you have JIRA Software, Core and Service Desk installed you want to divide your
users up into the application default groups – jira-software-users, jira-core-users and jira-
servicedesk-users. But if you specify jira-software-users, jira-core-users and jira-servicedesk-
users in Default Group Memberships, all your LDAP users will be added to all three groups. It
may be easier in that case to leave Default Group Memberships blank and use your existing
LDAP groups e.g. Marketing, Customer Service, etc. to do bulk adds to default groups in JIRA.
(We will cover this scenario in the lab.)

78 - JIRA Administration Part 1

 There are two main ways to add users in JIRA.
1. Create users
•  Add user and specify application access – this will determine their default group(s). If you
are using the JIRA Internal Repository or an external user repository such as LDAP set up
for Read/Write for your users, the JIRA Administrator would create the users. However, if
you are using an external user repository set to read only and you want all your users
stored there, then the user would be created by the LDAP Manager. If you have the
external directory set to Read Only, with Local Groups, you can also create a user locally
in the Internal user repository but you would then have users in both JIRA and the
external repository.
•  Send mail notification (optional)
•  Add user to any other required groups if necessary
•  Creating a user manually in JIRA is the only way you can set the user's password. You
cannot do this when you invite a user.
2. Invite users
•  Send invitation and specify application access – this will determine their default group(s)
•  User auto-added on response
•  Add user to any other required groups if necessary
You can invite one or more users to JIRA applications via email. When the users accept the
NOTES CONTINUED ON NEXT SLIDE

79 - JIRA Administration Part 1

 NOTES CONTINUED FROM PREVIOUS SLIDE
invite and they are created in JIRA, they will be given access to the applications set as default.
Note, JIRA's SMTP mail server must be configured to send notifications before you can invite
users via email.
Each invitation can only be used to create a user under the email address that it was sent to,
and can only be used once.
Each invitation will expire seven days after the day it was sent.
Your user license count will not be affected until users accept the invitation and the users are
created.
It is also possible to create users in the following ways:
•  The mail handler creates a user when issue/comment creation emails are received from
unknown users.
•  Allowing users to sign up via public signup.

80 - JIRA Administration Part 1

81 - JIRA Administration Part 1
 You as the Administrator need to decide if it’s right for your organization. Decide what sort of
people need access. There are some that will always need access, such as developers, and
you would most likely add them via create. However, it might be the case that there’s a
situation where Users need access as a sort of one-off. For example, the sales team might
need access to a project, but only to that project and only as needed. You can invite them, and
they will only use that account if they need it.

82 - JIRA Administration Part 1

 Use a consistent naming convention. For example:
<first letter of first name ><last name>
jsmith, agrant, hjennings …
Do not include email-address in user names.
User names must be unique.

83 - JIRA Administration Part 1

 The answer is on the next slide.

84 - JIRA Administration Part 1

 b. (Selecting the application they will access.)

85 - JIRA Administration Part 1

 The answer is on the next slide.

86 - JIRA Administration Part 1

 c. (Both groups)

87 - JIRA Administration Part 1

 Application Access best practices:
We strongly recommend you only have one default group for each application. New users
created and assigned application access are added to that application's default group. If this
group is also assigned to an additional application, the new user will also gain access to the
additional application. For example, if you assign a group called Group A to JIRA Software
and make it the default group, all new users added to JIRA Software will be added as
members of Group A. If you then add Group A to JIRA Service Desk, all users in Group A will
now have full access to both JIRA Software and JIRA Service Desk. This also means that when
you create a new user and add them to JIRA Software, they will also gain access to JIRA
Service Desk and consume a license for both applications.
If you have installed multiple applications, jira-administrators will only be added automatically
to the first application installed/licensed. Being an administrator means you have access to the
administration pages and can change settings and create projects. But to be able to view or
work in projects you need to be in a group that has the appropriate application access.
We’ll cover project specific permissions later in the course.

88 - JIRA Administration Part 1

 Optional: Deactivate a user, troubleshoot a user login issue and explore default application
access settings for new users

89 - JIRA Administration Part 1

 A chance for you to give feedback about the lab. What did you find interesting? Did you get
stuck? What did you learn?

90 - JIRA Administration Part 1

 An opportunity to ask questions.

91 - JIRA Administration Part 1

92 - JIRA Administration Part 1
 This is the location of the Atlassian offices in Austin, USA.

93 - JIRA Administration Part 1

94 - JIRA Administration Part 1
 Permissions are settings within JIRA applications that control what users within those
applications can see and do. All JIRA applications allow a variety of permissions: from whether
users can create new projects to whether a user can see a specific type of comment on an
issue. These permissions can differ between applications.
Permissions are different from application access, which is controlled by groups that have Use
access for an application.

95 - JIRA Administration Part 1

 Global permissions allow you to control functionality that is system wide and project
independent. For example, whether users can see the other users in the application. Global
permissions are granted to groups of users and can only be modified by JIRA Administrators
or JIRA System Administrators. See next slide for list.
Project specific permissions let you restrict project related functionality to individual users,
groups or project roles. For example, who can see the project's issues, create, edit and assign
them. Project specific permissions and project roles are covered later in the course.

96 - JIRA Administration Part 1

 Each of these global permissions is explained on the next slides.
Don’t get the JIRA System Administrators and JIRA Administrators global permissions
confused with groups
Third party plugins can also define additional global permissions.
In 7.0, there is no longer a jira-users permission (this is now handled through application
access.)

97 - JIRA Administration Part 1

 People who have the JIRA System Administrators permission can perform all of the
administration functions in JIRA, while people who have only the JIRA Administrators
permission cannot perform functions which could affect the application environment or
network. For example, configuring the JIRA’s SMTP mail server for notifications, configure
listeners, access logging and profiling information, configure listeners, and so on. This
separation is useful for organizations which need to delegate some administrative privileges
(e.g. creating users, creating projects) to particular people, without granting them complete
rights to administer the JIRA system.
For a list of the things that JIRA System Administrators can do that JIRA Administrators cannot
do see https://confluence.atlassian.com/display/AdminJIRAServer070/Managing+global
+permissions. You will look at this page in the lab.
If you only have JIRA Administrator permission you cannot grant yourself JIRA System
Administrator permission.
In the Cloud you only get JIRA Administrators - there are no JIRA System Administrators. This
is because those functions are handled for you in a JIRA Cloud environment.

98 - JIRA Administration Part 1

 By default the jira-administrators group has both JIRA System Administrators and JIRA
Administrators global permissions. Also by default, the user account created during the JIRA
setup wizard is a member of this jira-administrators group.
In your JIRA instance, you might separate the groups who can access these permissions so
that you reduce the number of “dangerous” or deeper changes to a limited number of users.
Smaller companies may have one person or group with both permissions but at the enterprise
level they would probably separate them.
When you choose to separate administrators into different categories of privileges (JIRA
Administrators and JIRA System Administrators), you are saying that some of your
administrators should not be allowed to make certain system-wide configurations. This is
useful if the expertise to make those changes resides in a small number of people. The
downside to limiting the administrator privileges for JIRA Administrators is that they sometimes
need assistance to configure JIRA. You should balance limiting privileges with how responsive
system administrators can be to requests for assistance.
If you need some people to have only the JIRA Administrators permission (and not the JIRA
System Administrators permission), you need to use two separate groups.

99 - JIRA Administration Part 1

 The Browse Users global permission is used for selecting users/groups in popup screens that
appear throughout JIRA. Enables auto-completion of user names in most 'User Picker' menus
and popups. Whatever group you grant this to can see everyone else, which is a consideration
if JIRA is accessible externally.
This is used, for example when sharing dashboards or filters.

100 - JIRA Administration Part 1

 The Create Shared Objects global permission enables users to share a filter or dashboard
globally or with groups of users. Also used to control who can create an Agile board.

101 - JIRA Administration Part 1

 The Bulk Change global permission gives users the ability to execute the bulk operations
within JIRA - Bulk Edit * , Bulk Move *, Bulk Workflow Transition, Bulk Delete *
( * subject to project-specific permissions – we’ll discuss those in a later module.)
Users with this permission would have the ability to modify a collection of issues at once. For
example, resolve multiple issues in one step.
The decision to grant the Bulk Change permission should be considered carefully. This
permission grants users the ability to modify a collection of issues at once. For example, in
JIRA installations configured to run in Public mode (i.e. anybody can sign up and create
issues), a user with the Bulk Change global permission and the Add Comments project
permission could comment on all accessible issues. Undoing such modifications may not be
possible through the JIRA application interface and may require changes made directly against
the database (which is not recommended).

102 - JIRA Administration Part 1

 The Manage Group Filter Subscriptions global permission lets users manage (create and
delete) group filter subscriptions.
For example, as an individual you can create a search filter. Then through Manage Filters you
can set up a subscription and add an individual which means you get an email of the results of
that filter every so often – you set the timing of the emails. The Manage Group Filter
Subscriptions permission allows you to set the subscription to a group instead of an individual.
Be careful with this as a user with this permission could SPAM a bunch of other users by
sending it to a wide audience and sending it often (even every 5 minutes if you wanted).

103 - JIRA Administration Part 1

 Global permissions are assigned to groups. In this example a user with the JIRA
Administrators permission assigns the Create Shared Objects permission to the Development
group. Many people think that these can be added to or further defined, but they can’t be.
Users with JIRA Administrators or JIRA System Administrators can assign global permissions.

104 - JIRA Administration Part 1

 These are the default global permissions that are assigned to the default JIRA groups. So if all
your users in JIRA (apart from Administrators) are members of one of these default groups they
will have all four non administration global permissions by default.
We’ll discuss Administrator permissions more in the next few slides. When you install JIRA, the
default Administrator, admin, is part of the jira-administrators group and so has both JIRA
System Administrators and JIRA Administrators permissions.

105 - JIRA Administration Part 1

 Answers on next slide

106 - JIRA Administration Part 1

 Answers:
1.  B and c.
2.  A True

107 - JIRA Administration Part 1

108 - JIRA Administration Part 1
 Best Practices
The Browse Users global permission is used for selecting users/groups in popup screens.
Enables auto-completion of user names in most 'User Picker' menus and popups. Whatever
group you grant this to can see everyone else, which is a consideration if JIRA is accessible
externally.
The decision to grant the Bulk Change global permission should be considered carefully. This
permission grants users the ability to modify a collection of issues at once. For example, in
JIRA installations configured to run in Public mode (i.e. anybody can sign up and create
issues), a user with the Bulk Change global permission and the Add Comments project
permission could comment on all accessible issues. Undoing such modifications may not be
possible through the JIRA application interface and may require changes made directly against
the database (which is not recommended).
Permissions might get pretty complex if many groups and roles are involved so you might want
to keep it simple.
Think about possible implications when adding groups to global permissions. (E.g. if users are
able to bulk update issue and they also have the project permission to delete issues, they can
bulk delete issues.)

109 - JIRA Administration Part 1

110 - JIRA Administration Part 1
 A chance for you to give feedback about the lab. What did you find interesting? Did you get
stuck? What did you learn?

111 - JIRA Administration Part 1

 An opportunity to ask questions.

112 - JIRA Administration Part 1

113 - JIRA Administration Part 1
 This is the location of the Atlassian offices in Yokohama, Japan.

114 - JIRA Administration Part 1

115 - JIRA Administration Part 1
 What do we do when we’re managing projects?
-  Every organization consists of people working on tasks to produce a desired outcome, or in
other words, a project.
-  A project can be a non-technical, such as moving an office or it can be technical, such as
development of software or building something such as an engine in an engineering team.
-  In any kind of Project Management, we break down the desired outcome into tasks,
estimate how long the tasks will take, assign the tasks to resources, and plan dates for
when those tasks will be completed, and build a roadmap for when the beta or next iteration
can be released.
-  Depending on the organizational structure, there will be different ways that work is
organized – but in the end it comes down to people working on tasks and completing the
tasks inside a time frame.
We can plan and manage our project using all types of different methods. Traditionally people
have used spreadsheets, word docs, sticky notes, binders filled with paper, all of which exist in
silos of content. The problem here is the lack of the ability to scale and be accessible across
teams.
How many of us have had the situation where even in the best meeting, gathering good team
input still is not productive. By the time we get back to our desks and update our meeting
notes in to the system, they are already out of date.
NOTES CONTINUED ON NEXT SLIDE

116 - JIRA Administration Part 1

 NOTES CONTINUED FROM PREVIOUS SLIDE
Getting information out of spreadsheets and Word documents takes time, and is very quickly
out of date. When teams are not co-located the challenges expand with duplicated materials,
unable to access information, rework, and communication issues.
Management and Reporting from spreadsheets is:
•  Time consuming
•  Not shared
•  Kept in silos, not accessible to the team
•  Manually updated
•  Requires manual reporting

117 - JIRA Administration Part 1

 This is where JIRA helps out with the challenge. In JIRA, projects are created and associated
with tasks, resources, and schedules. Tasks are represented as issues. At it’s most simple, a
project is a collection of issues. The building blocks of any project are issues. Issues act as the
packets of work that travel through their respective workflows within their projects, until the
work is completed.
All of these things need to be managed. All of these tasks need to be monitored. JIRA has in-
built features and functionality that helps you to manage these projects, the people involved in
them and the tasks that need to be completed.
In this example we are working on a software development project to create a iPhone app for
Teams in Space. It allows all life forms to book travel from Mars. Teams are located across the
universe and JIRA is the ideal solution to help the team collaborate.
Your team could use a JIRA project to coordinate the development of a product, track a
project, manage a help desk, and more, depending on your requirements. A JIRA project can
also be configured and customized to suit the needs of you and your team.

118 - JIRA Administration Part 1

 Team members or users manage and work on the tasks in the project. These tasks are
described in issues.
In a project there are different task types for managing things like bugs, feature requests.
These are different because they have different business processes behind them and gather
different kinds of information that is necessary to complete them. This example is a software
project, but we could manage any other kind of project in JIRA, anything that has tasks that
need to be monitored. Issues represent different task types, or issue types in JIRA.
JIRA projects are a way of grouping issues together and a way of applying the same sets of
configurations to issues. These configurations, such as workflow, issue types and screens, can
be changed on a per project basis, so that each project can have a different set of
configurations. Setting up a JIRA project effectively will enable your users to manage and
complete their work quicker and more efficiently.
Data, needs to be captured such as which version of iOS a bug manifests itself, or what status
the task is in (open, complete). Data is automatically gathered to provide reports on project
status and metrics. We need to know how many issues are still open, how many closed, how
much time has been logged, how much time of the initial estimate is remaining.
Issues have associated workflows, because different tasks have different processes
associated with them. Workflows define the business process for each task type.
NOTES CONTINUED ON NEXT SLIDE

119 - JIRA Administration Part 1

 NOTES CONTINUED FROM PREVIOUS SLIDE
Versions define a release version, milestone, or a phase pending on the business process.
Issues are then packaged together and released. Versions let you categorize content to
manage the tasks. For example, it would be useful to know how many tasks are remaining in
the release 1.1. We can associate the tasks with a release, such as 1.0, and make sure that all
of the tasks planned are complete, or managed if they are not complete.
Components define sub-categories or groupings of the project. Issues can belong to software
components such as UI or database.

120 - JIRA Administration Part 1

 Each of the three JIRA applications is suited to different types of projects.
JIRA Software is ideal for creating software development projects. For example, to develop a
new Cloud application.
JIRA Service Desk is ideal for any kind of Help Desk application. For example, an IT Help Desk.
JIRA Core is ideal for any business application, for example:
•  HR use it to manage candidate tracking and employee onboarding
•  Finance use it to manage tracking and procurement processes
•  Marketing use it to manage review cycles and marketing collateral

121 - JIRA Administration Part 1

 Depending on which JIRA applications you have installed, you may have more than one
project type available. The project types are Software (if you have JIRA Software installed),
Service Desk (if you have JIRA Service Desk installed) and Business (if you have JIRA
Software, Service Desk or just JIRA Core installed). Each project type has specific features.
Each project type has a number of project templates available as you see here. Project
templates are sets of pre-configurations which are the default starting points.
For example, Software projects give you the following templates:
•  Scrum software development: This project provides you with a template for Scrum software
development, including a Scrum board and Agile-specific issue types, like Story and Epic.
•  Kanban software development: This project provides you with a template for Kanban
software development, including a Kanban board and agile-specific issue types, like Story
and Epic.
•  Basic software development: This project provides you with a template to use for software
development.
Once you create a project, users can go to work with the defaults or you can customize them
to suit your needs.
You can convert a project from one type to another (as long as the application is installed.) For
instance, you can convert a JIRA Software project to a JIRA Core project at the end of a JIRA
Software evaluation period, or when your team grows. You can only convert to project types
of JIRA applications that you have installed.

122 - JIRA Administration Part 1

 As the JIRA administrator, you act as the project creator for your JIRA community. A user who
has the JIRA Administrators global permission, the JIRA administrator, is able to create
projects for all applications installed. If the administrator does not have application access for
that application, they will not be able to see the project’s issues or use project related
functionality in the project after they have created it. If you're creating a project using a project
type related to an application you currently do not have access to, JIRA will display a
checkbox that will allow you to grant yourself access to that application. This will add you to
the default group of that application, and you will count as a user for that license.
See https://confluence.atlassian.com/adminjiraserver070/defining-a-project-749382822.html.
We’ll discuss project permissions in the next module.

123 - JIRA Administration Part 1

 Use a descriptive name for the project so it’s easy to find.
The project key will be used as the prefix of this project's issue keys (e.g. ’HR-100'). Choose
one that is descriptive and easy to type. The key can be changed but it is not a trivial task. By
default it is the first letter of each word of the name.
If available, provide URL to Confluence space, document repository, etc. for project
documentation.
An Avatar (icon) makes the project easier to find. You can use one of the provided avatars or
your own image. If you don't want to use a project avatar, you can upload a transparent pixel.
This effectively loads the transparent pixel, which means you won't see an image.
As a JIRA administrator, you need to manage many projects, many that you are not involved
in. A description makes it clear what the project is for and if you can provide a URL to for e.g..
A Confluence space, more info can be found there. You can include HTML in the project
description, but make sure all your HTML is valid. Please be aware that this is completely
unfiltered HTML and as such, it is susceptible to cross-site scripting attacks.

124 - JIRA Administration Part 1

 JIRA enables you to keep track of different types of things — bugs, tasks, helpdesk tickets,
etc. — by using different issue types. Issue types define the configurations that support the
process of that issue (such as Bug, Task, Epic, Story…) When creating a project, project-
specific issue types are established by default and the JIRA Administrator can add/edit Issue
types as necessary to support the business process. You can also configure each issue type
to act differently, (e.g. to follow a different process flow or track different pieces of information).
An Issue Type is an issue with fields and workflows that are used to progress an issue to
completion.
Here you see the default issue types for Software and Core projects. After installation you only
see a few issue types – more are created as you create projects of different types.
Default issue types for Software and Core (for Core it’s just Task and Sub-task):
•  Task — Work that needs to be done.
•  Sub-task – A piece of work that is required for a task. Can be disabled on the Sub-tasks
administration page.
•  Bug — A problem that impairs or prevents the functions of a product.
•  Story – The work to develop some deliverable feature.
•  Epic – A big user story that needs to be broken down.
•  Improvement — An enhancement to an existing feature.
•  New Feature — A new feature of the product.

125 - JIRA Administration Part 1

 Service Desk behaves differently than the other project types. JIRA issue types are the
underlying objects for request types. One issue type can be the base for one or more request
types. When you customize what customers see on the Customer Portal by modifying the
request types with the service desk interface, you are changing the display of JIRA fields. The
Project administrator or JIRA administrator can do this. There are two project templates for
Service Desk – Basic Service Desk and IT Service Desk. Here we’ll cover Basic Service Desk.
IT Service Desk is more complicated and is beyond the scope of this course.
Basic Service Desk Issue Types:
•  Access – Requesting additional access.
•  Fault – Reporting a fault.
•  IT Help – Requesting help for IT related problems.
•  Purchase – Requesting hardware or software.
New JIRA Service Desk projects come with two request types set up and each of them maps
to an issue type (as shown above):
•  Request a new account maps to JIRA Issue type Access - Request a new account for
an internal system.
•  Get IT Help maps to JIRA issue type IT Help - Get help for IT problems and questions.
See https://confluence.atlassian.com/servicedesk/issue-type-660967505.html and https://
confluence.atlassian.com/adminjiraserver070/default-service-desk-project-
configuration-776637117.html.

126 - JIRA Administration Part 1

 Workflow is all about managing your tasks and teams – it’s the work process. All tasks needs
to go through a specific workflow, even if that’s just a few steps or statuses; open, in progress,
resolved, closed.
As an organization grows, it begins to develop a unique culture based on how its employees
work together within small teams. And a huge part of how a team functions relies on its
workflow, a repeatable process which allows people to work together at scale.
Once you have a workflow, you can manage your tasks. (For example, what stage are my 20
issues in this project.? 2 closed, 6 resolved, 6 in progress, 6 open.) There’s saying that what
cannot be measured cannot be managed and it’s true. If you don’t have any way to measure
where your tasks are within their lifecycle, then how can you manage them? As a Product
Manager, it’s easier if I know this information. Also this means you can gather data and show
that data in gadgets and charts in dashboards. This allows you to monitor the progress of your
project. What is your team working on at the moment? How long are open cases remaining
unassigned? Can we reach our deadline?

127 - JIRA Administration Part 1

 The workflow defines our process for completing the tasks – what actions need to occur, when
and by who. And it ultimately defines a process that the issue must go through to complete. It
is a business process, with stages that an issue goes through to reach its final status. Your
JIRA issues can follow a process that mirrors your team's practices. A workflow defines the
sequence of steps (or statuses) that an issue will follow, (e.g. Open, In Progress, Resolved).
You can configure how issues transition between statuses, (e.g. who can transition them,
under what conditions, and which screen will be displayed for each transition). It is the flow of
work through your organization.
Each issue has a workflow and you can define different workflows for different issue types.
As an example you see here a very simple workflow for a library. A book is either at the library
or with a customer. A customer checks books out and checks them in.
Workflow is the backbone of how JIRA works within your organization; taking the time to
customize the workflow to meet your business needs will pay many dividends down the line.
And, it’s the JIRA Administrator who creates and configures workflows in the organization.
See https://confluence.atlassian.com/adminjiraserver070/working-with-
workflows-749383109.html and http://blogs.atlassian.com/2013/10/building-workflow-
awesome.

128 - JIRA Administration Part 1

 Here you see the default workflows for each of the templates for the Software project type.

129 - JIRA Administration Part 1

 Here you see the default workflows for each of the templates for the Business (Core) project
type.

130 - JIRA Administration Part 1

 JIRA Service Desk creates and associates each new service desk project with a default
workflow, named ‘JIRA Service Desk IT Support Workflow generated for Project <PROJECT
KEY>’. This is used in Basic Service Desk projects and is one of the workflows created for IT
Service Desk projects. IT Service Desk projects also have two more workflows created, JIRA
Service Desk Change Management and JIRA Service Desk Problem Management.
The default workflow has a few default statuses and the status names are converted into
customer-friendly names on the customer portal via workflow status mappings. Status
mappings can be specified per request type.
For a table of default statuses and status names shown to customers see https://
confluence.atlassian.com/adminjiraserver070/default-service-desk-project-
configuration-776637117.html.

131 - JIRA Administration Part 1

 As an example of workflow, libraries have well-known workflows surrounding materials they
lend out to the public. Each item (e.g. book, magazine, etc.) could be stored in a JIRA as an
issue and administered in the workflow shown here.
A workflow has four unique components: statuses, transitions, assignees, and resolutions.
•  Statuses represent the position of the issue within a workflow. End users see them in the
issue. In the library example, a book can be in one of three places: at the library, with a
customer, or retired from inventory. Every status should be unique state in your workflow.
Status must describe what has already happened. Keep statuses to a minimum.
•  Transitions are the bridges between statuses; the way a particular issue moves from status
to status. At the library, books are loaned out by librarians, returned by customers, and
evaluated by library staff to see if they’re fit for circulation. Note that customers cannot
evaluate if an item is fit for inventory – that must be decided by the library staff. JIRA is able
to set workflow permissions that allow only the right people to transition an issue. You can
also, optionally, use screens to gather data/information during transitions.
•  Assignees - Workflows guide how people work together. In JIRA, the assignee dictates the
responsible party for any given issue. In the library example, we would set the assignee to
the borrower every time a book is loaned out, so that the library knows which customer has
that book. When the book is returned from inventory we would then remove the assignee
when we transition the book back to inventory.
NOTES CONTINUED ON NEXT SLIDE



132 - JIRA Administration Part 1
 NOTES CONTINUED FROM PREVIOUS SLIDE
•  Resolutions explain why an issue transitions from an open status to a closed one. The act
of retiring a book removes it from inventory, therefore, we can put a resolution on that book.
We might use resolutions of damaged, out of date, lost, etc. The two biggest mistakes new
JIRA administrators make are:
•  Confusing resolution with status – Status describes where an item is in the workflow;
resolution explains why an item is not in flight anymore. In order to effectively use these
features to retire a book from circulation, our librarian should create a status called
retired, and options for resolution that include things like lost, damaged, out of date, etc.
Searching for everything that’s retired (or resolved) – with the ability to search for why it’s
retired, using the resolution options – gives much better reporting metrics. JIRA uses
resolution to know if the issue is considered inactive by the organization. The best way to
check to see if you’ve got it right is to use the created versus resolved gadget. You can
have a workflow between when an issue is resolved and officially closed. Many
organizations verify resolved issues to ensure they are resolved for the right reasons.
•  Setting resolution correctly – You must set a resolution when an issue moves from an
open state to a closed state. Likewise, resolution needs to be removed when an issue
gets reopened. At the library, if the librarians decide to put the book back into circulation
the workflow, they would need to remove the resolution from that book. For example, a
book that is able to be checked out should not have a resolution of lost.

133 - JIRA Administration Part 1

 When you create a project, the project gets it’s own copy of the workflow for the project type
and template. So you can change it and the changes will only apply to that project.
You can't modify a 'live' workflow, you can only edit a draft copy of the live workflow. Then
you publish the draft which replaces the live workflow. You also get the option to save the
original workflow as a backup copy. It’s always a good idea to do this in case you ever want to
revert back to the original workflow or use it somewhere else.
Create a new workflow using one of these methods:
•  Cloning an existing workflow – you can copy the live workflow, edit the copy - find it listed
under inactive workflows - then modify workflow schemes to use edited workflow.
•  Creating a new workflow.
•  Importing a workflow – either locally or from the Atlassian Marketplace.
We will not cover advanced workflow options in this class (conditions, validators, post
functions, and transition screens.) See the Getting More from JIRA Workflows course.
Test with copies of the workflow scheme - ideally in a test or staging environment. Because
the issues themselves are migrated, changes you make may not be able to be undone easily.
For information on advanced workflow configuration, see https://confluence.atlassian.com/
adminjiraserver070/advanced-workflow-configuration-749383189.html and http://
blogs.atlassian.com/2013/10/building-workflow-awesome/.
NOTES CONTINUED ON NEXT SLIDE

134 - JIRA Administration Part 1

 NOTES CONTINUED FROM PREVIOUS SLIDE
Performance notes on modifying workflows:
•  The number of issues impacts the speed when configuring a workflow - for small numbers
of issues, this process is relatively quick, however if you have many (e.g. thousands of)
existing issues in your JIRA project, this process may take some time.
•  Once this process begins, it cannot be paused or cancelled. Please avoid editing or
transitioning any issues within your project while this process is taking place.

135 - JIRA Administration Part 1

 Answers on next slide

136 - JIRA Administration Part 1

 Answers:
1.  b, you only need JIRA Administrators global permission to create projects. You would
need Application access to view the project you created.

137 - JIRA Administration Part 1

 Answers on next slide

138 - JIRA Administration Part 1

 Answers:
1.  c, Each project template comes with only the issue types that are applicable to that
project template, however you can add more issue types.
2.  It’s easy to confuse resolution with status – Status describes where an item is in the
workflow; resolution explains why an item is not in flight anymore. In order to effectively
use these features to retire a book from circulation, our librarian should create a status
called retired, and options for resolution that include things like lost, damaged, out of
date, etc. Searching for everything that’s retired (or resolved) – with the ability to search
for why it’s retired, using the resolution options – gives much better reporting metrics.
That’s why JIRA uses resolution to know if the issue is considered inactive by the
organization. The best way to check to see if you’ve got it right is to use the created
versus resolved gadget. You can have a workflow between when an issue is tagged
with a resolution and officially closed. Many organizations verify resolved issues to
ensure they are resolved for the right reasons.

139 - JIRA Administration Part 1

 Best Practices
Gather all your stakeholders - Workflow is about scaling culture, and culture is about people.
Whenever it comes time to build a process around a set of people, identify all of the
stakeholders in that workflow. For example, if you’re trying to build a workflow between
product management, software development, and support, ensure you have one
representative from each organization in the meeting. As the person designing the workflow,
spend time talking with each stakeholder about what’s important to them. Before the meeting
starts, draw a draft workflow on the whiteboard, then walk through each case in the meeting
and gather stakeholder feedback. Workflows are touchy as they govern how people work; be
patient, and your investment will pay off later. Use a whiteboard in low fidelity so it’s easy to
get feedback and make changes at this stage.
Keep the workflow simple - Most of the time stakeholders want to have statuses for each
part of the workflow. Generally that’s a good thing, but remember: each status adds more
transitions and complexity to the workflow. Workflow is designed to make things simple and
scalable. Whenever adding a new status to a workflow, ensure that the stakeholder has no
other option but to grow the workflow. Let’s look at two examples:
1. In many organizations, code review is an important part of the software development
process. Jane, the development manager, wants to add a specific status called code review so
that it’s clear to the team what issues are under active development, and which issues
NOTES CONTINUED ON NEXT SLIDE

140 - JIRA Administration Part 1

 NOTES CONTINUED FROM PREVIOUS SLIDE

are waiting review. Reviewing code is distinctly different than writing code. It makes sense to
add a new state as the review process indicates that development is done, and that somebody
else is now responsible.
2. Bill, the test manager, wants to add new status called rejected for all issues that don’t pass
review by his team. I’d advise against doing this, as the test engineers can simply reopen any
issue that fails review. An alternative option is to move the issue into a resolved state with the
resolution rejected.
Confusing resolution with status – Status describes where an item is in the workflow;
resolution explains why an item is not in flight anymore. For example, in a library example, to
retire a book from circulation, our librarian should create a status called retired, and options for
resolution that include things like lost, damaged, out of date, etc. Searching for everything
that’s retired (or resolved) – with the ability to search for why it’s retired, using the resolution
options – gives much better reporting metrics. That’s why JIRA uses resolution to know if the
issue is considered inactive by the organization. The best way to check to see if you’ve got it
right is to use the created versus resolved gadget.
Save a backup - When you publish a draft, save the original workflow as a backup copy. It’s
always a good idea to do this in case you ever want to revert back to the original workflow or
use it somewhere else.

141 - JIRA Administration Part 1

142 - JIRA Administration Part 1
 Here we see a Create Issue screen. This is and example of using JIRA to manage a wine cellar.
A screen is the user’s view of an issue and is simply a collection of fields. They are the data
entry/view/edit mechanism for issues. The screen is mapped to a specific issue operation
(such as creating an issue, or editing an issue). JIRA allows you to display particular pieces of
issue information at particular times, by defining screens. You can choose which screen to
display when an issue is being created, viewed, edited, or transitioned through a particular
step in a workflow.
Information for each issue is held in the fields that are associated with that issue. You can tailor
these fields to suit your organization's needs.
JIRA enables you to define field behavior: each field can be required/optional, rich text/plain
text, hidden/visible. You define this behavior by using a field configuration. Don’t create a lot of
fields on a screen. Too many fields means users will leave half of them empty and you can't
drive business on bad data.
Removing a field from a screen will not delete the existing data, nor will it affect search or
reporting. However, if you delete the field itself (not just remove it from a screen), it will destroy
the data in the field.
See http://blogs.atlassian.com/2014/05/life-runs-jira-sommelier-edition/.

143 - JIRA Administration Part 1

 Issues can be grouped in JIRA by using versions. For example, if you are using JIRA to
manage the development of a product or manage the build of a house, you may want to define
different versions to help you track which issues relate to different phases of your product or
build (e.g. 1.0, 1.1, 1.2, 2.0, 2.0.1). JIRA can help you manage, release and archive your
versions. Versions can also have a Release Date, and will automatically be highlighted as
"overdue" if the version is unreleased when this date passes. Versions are defined in the
project. They help build out the roadmap for the project.
Versions are typically used in Software projects.
Versions are managed by Project Administrators – we’ll discuss Project Administrators in the
next module.

144 - JIRA Administration Part 1

 Components are logical groups that a project's issues can belong to. They are used to group
issues within a project into smaller parts. If you don’t want to split up your system into too
many projects, components are a great way to group issues.
In this example, we’re developing an iOS app and have a Software project. An App naturally
consist of components such as UI, Database, User Settings etc. (Note that issues can belong
to more than one component). You can choose a Default Assignee for each component, which
is useful if you have different people leading different sub-teams in your project. The default
assignee for a component will override the project’s default assignee, for issues in that
component. If an issue has multiple components, and the default assignees of components
clash, the assignee will be set to the default assignee of the component that is first
alphabetically.
Typically you have a lead developer to manage the tasks related to those components. In
JIRA, you can easily add components and set up component leads– so that the team member
who manages issues of this type gets assigned the correct issues.
See https://confluence.atlassian.com/adminjiraserver070/managing-
components-749382865.html.

145 - JIRA Administration Part 1

 This shows the organizational hierarchy of Teams in Space. The Organizational Units are
defined by the organization and are outside JIRA. The Project Categories and Projects are
created within JIRA. A JIRA project can only belong to one category. Please note that a project
category is not part of a project hierarchy. Also, JIRA does not support sub-projects or parent
projects, that is, you cannot nest projects. (The ‘i’ icon is for an informational note.)
Why are categories useful? JIRA can search for all the issues in a particular project category,
for example “App Dev” in an advanced search, and can display projects sorted by the project
category. These are useful in large enterprise installs.

146 - JIRA Administration Part 1

 Schemes are probably one of the biggest source of confusion for somebody who is relatively
new to JIRA administration, but once you understand the core concept, they are a great way to
reduce your administrative overhead while keeping your flexibility up. A scheme is a container/
collection of configuration items. There are many different types of schemes (seven in all) and
each one behaves slightly differently. For example there are workflow schemes, issue type
schemes, field configuration schemes, screen schemes, and so on. Schemes allow you to
package up configurations and then re-use them in other projects (more on that soon).
Here you see an example of an issue type scheme that is the default for Software type
projects. It contains all the default issue types for that type of project.

147 - JIRA Administration Part 1

 Here’s another example of a scheme. A workflow scheme allows you to define which
workflows apply to which issue types and projects. Here the HR: Project Management
Workflow Scheme is used in the Human Resources project. There are two workflows in this
scheme – HR: Project Management Workflow which is applied to all unassigned types and
Original HR: Project Management Workflow which applies to the Person issue type. Similarly,
the project's screen scheme determines which screens are displayed for different issue
operations (view, edit, create).

148 - JIRA Administration Part 1

 Each new project gets it’s own fresh set of schemes based on the default schemes for its
project type and project template. For example, if you created the iOS App project using the
Scrum Software Development template, the project will get it’s own workflow scheme which is
a copy of the default workflow for this type of project. You can then edit and customize these
schemes for your project without changing the default schemes. The schemes copied are for
issue types, workflows, screens and issue type screens. This is a simplified diagram as not all
default schemes are automatically copied when you create a new project. These are
permission schemes and notification schemes. If you want to have these schemes customized
for your project, you need to manually copy them first. One exception to this is the field
configuration scheme which is automatically copied when a Service Desk project is created.
Schemes are useful because you can share them between projects. Once you’ve configured a
project the way you want it with your own issue types, workflows, etc. you may wish to use
that same configuration in another project. Schemes allow you to do that. In the example
shown here, when you create the iOS App project, it’s created with a copy of the default
schemes. You then customize those schemes perhaps adding some issue types to the issue
type scheme and a new workflow to the workflow scheme etc. Then you want to create a very
similar project for the Android App. So when you create that project you choose to share the
iOS App project’s schemes thus saving you all the work of customizing the issue types and
workflow again. This is just a brief introduction to schemes. We’ll cover schemes in more
detail, and how to share schemes between projects, in the next two modules in the course.

149 - JIRA Administration Part 1

 Answers on next slide

150 - JIRA Administration Part 1

 Answers:
1.  C, a screen is mapped to a specific issue operation such as creating an issue or editing
an issue.

151 - JIRA Administration Part 1

 Answers on next slide

152 - JIRA Administration Part 1

 Answers:
1.  The following are true:
A, a project can have many components
C, a project category can contain many projects
D, a project can belong to only one category

153 - JIRA Administration Part 1

154 - JIRA Administration Part 1
 Best Practices
Don’t create a lot of fields on a screen. Too many fields means users will leave half of them
empty and you can't drive business on bad data.
Removing a field from a screen will not delete the existing data, nor will it affect search or
reporting. However, if you delete a field, it will destroy the data in the field.
If you don’t want to split up your system into too many projects components are a great way to
group and categorize issues. Why are categories useful? JIRA can search for all the issues in a
particular project category, for example “App Dev” in an advanced search, and can display
projects sorted by the project category. These are useful in large enterprise installs.
More on sharing project configuration (schemes) in the next two modules.

155 - JIRA Administration Part 1

156 - JIRA Administration Part 1
 A chance for you to give feedback about the lab. What did you find interesting? Did you get
stuck? What did you learn?

157 - JIRA Administration Part 1

 An opportunity for you to ask questions.

158 - JIRA Administration Part 1

159 - JIRA Administration Part 1
 This is the location of the Atlassian offices in San Francisco, USA.

160 - JIRA Administration Part 1



161 - JIRA Administration Part 1

 By using project roles and permissions correctly you can effectively and efficiently manage all
the different permissions different users need in different projects.
Project roles and permissions allow you to:
•  Control what tasks users can perform in a project e.g. browse the project, create issues,
edit comments, etc. using project permissions.
•  Assign the Project Administrator, Project Lead, and Default Assignee default project roles to
quickly give the right people the appropriate permissions.
•  Create project roles and use these in permission schemes as a powerful way to control
what users can do in a project.

162 - JIRA Administration Part 1

 What features users can see and what actions they can take in a project are determined by
their application access and the project specific permissions. JIRA allows you to control who
can access your project, and exactly what they can do (e.g. "Work on Issues", "Comment on
Issues", "Assign Issues"), by using permissions for projects.
Recall that global permissions apply to the entire JIRA instance and are granted to groups.
These are for project independent functionality such as who can administer JIRA, perform bulk
updates, etc.
Permissions for projects apply only to projects and are independent from Global permissions.
There are 26 different permissions for projects and include such things as who has the ability
to assign issues in this project, or who can create issues, add attachments or comment on
them, who can browse the project, etc. These are much more granular than global
permissions.
They break down into different types:
•  Project Permissions e.g. administer and browse projects
•  Issue Permissions e.g. create and resolve issues
•  Voters & Watchers Permissions
•  Comments Permissions
•  Attachment Permissions
•  Time Tracking Permissions
NOTES CONTINUED ON NEXT SLIDE

163 - JIRA Administration Part 1

 NOTES CONTINUED FROM PREVIOUS SLIDE
For a list of all the permissions, see https://confluence.atlassian.com/adminjiraserver070/
managing-project-permissions-749382918.html.
You can also control access to individual issues by using security levels and issue security
schemes. These are beyond the scope of this course. See https://confluence.atlassian.com/
display/AdminJIRAServer070/Configuring+issue-level+security.

164 - JIRA Administration Part 1

 Permissions are defined in Permission Schemes that are then associated with projects by the
JIRA Administrator. The project's permission scheme determines who has permission to view
or change issues in this project. Here is an example of a Permission Scheme, the Development
Permission Scheme. As you can see it associates groups (jira-software-users), Roles (Project
Lead) and users (Alana Grant) with project level permissions.
Permission schemes allow you to create a set of permissions and apply this set of permissions
to any project. All permissions within a scheme will apply to all projects that are associated
with that scheme.
In this example, the permission requirements in all development projects are the same.
Someone in the role of an administrator can administer all DEV projects, all of the Teams in
Space users can have a look at what’s currently being worked on, but only developers should
be able to actually create issues. Teams in Space reuses this scheme in all of their dev
projects!
Project permissions are able to be granted to individual users, groups, project roles (we’ll
cover these soon), issue roles such as 'Reporter', 'Project Lead', and 'Current Assignee’, and
'Anyone' (e.g. to allow anonymous access).
Note that some permissions are dependent upon others to ensure that users can perform the
actions needed. For example, in order for a user to be able to resolve an issue, that user must
be granted both the Transition Issue permission and the Resolve Issue permission.

165 - JIRA Administration Part 1

 Why Permission Schemes?
In many organizations, multiple projects have the same needs regarding access rights. (For
example, only the specified project team may be authorized to assign and work on issues).
Permission schemes prevent having to set up permissions individually for every project. Once
a permission scheme is set up it can be applied to all projects that have the same type of
access requirements.
Permission schemes are associated with Projects. Each scheme can be shared, or you can
limit one project per scheme as you can see in the diagram.
Generally, as a JIRA Administrator you will create schemes that match your company-wide
processes, or Project types. You will generally have a number of projects and each belongs to
a certain category of project, such as a product dev project, or a client project, or an internal
project such as finance, marketing or sales. Each time you set up a new project you can chose
the scheme that reflects the type or project you set up. This is useful to you and your users as:
1.  You can manage the number of schemes and keep them to a minimum. Too many
schemes will make your life as a JIRA Admin painful.
2.  Your users will know how to work within the project as it’s the same as each of the others,
so you don’t need to educate them with each new project that you set up.
Different business cases have different permissions. As you can see here we have two different
projects with entirely different requirements regarding the permissions.
NOTES CONTINUED ON NEXT SLIDE

166 - JIRA Administration Part 1

 NOTES CONTINUED FROM PREVIOUS SLIDE
Our iOS project is relatively open, all jira-software-users can browse the project and see what’s
going on, and we just a single Project administrator who Is in charge of project versions etc. In
our internal HR project we have restricted access to our HR group and general management.
We also have a group (role) of people who can administer the project. We also have a mix of
groups and roles.

167 - JIRA Administration Part 1

 When you install JIRA it automatically creates the Default Permission Scheme. This is used
for, and shared by, any new Core (Business type) projects.
If you have JIRA Software installed and create a Software project, JIRA will create the Default
software scheme which will be used for, and shared by, any new Software projects.
JIRA Service Desk is different and will create a separate scheme for Service Desk project
created.
Here you see both Human Resources and Legal projects share the same Default Permission
Scheme and both Android App and IOS Application projects share the default software
scheme. Whereas the HR Help Desk and IT Help Desk projects have their own schemes.

168 - JIRA Administration Part 1

 As you can see here, this permission scheme is being associated with two projects. The
important thing to remember is that only JIRA administrators can modify schemes and
associate them with projects.
To be a JIRA Administrator you must have the JIRA Administrators global permission.

169 - JIRA Administration Part 1

 We have a new requirement. The Project Administrator for the Human Resources project wants
two consultants on her project to be able to create issues in her project temporarily. This would
mean they would need the Create Issues permission. What are the options? See next slide.
We will discuss the Project Administrator role later in this lesson.

170 - JIRA Administration Part 1

 Option 1 – use group to update default scheme:
1.  The Project Administrator requests JIRA Administrator to make the change.
2.  The JIRA Administrator creates the HR Consultants group and adds each consultant to
this group. The JIRA Administrator creates a new group called HR Consultants so he
doesn’t have to add individual users to the Create Issues permissions which isn’t a best
practice.
3.  The JIRA Administrator updates the Default Permission Scheme and adds the HR
Consultants group to the Create Issues permission.
4.  The JIRA Administrator communicates and documents the changes.
This would be an easy change for the JIRA Administrator to make. Is this a good option?

171 - JIRA Administration Part 1

 Recall that the Default Permission Scheme is used by all new Business (Core) type projects.
Since the Human Resources project is a Business project it would use this scheme by default.
The problem with adding the Consultants group to the Create Issues permission in the Default
Permission Scheme is that the consultants would have create issues permission in all Business
projects that use this scheme and also in any new Business project that’s created. For
example, if the Business project type was used for Human Resources and Marketing and
Sales projects, then the members of the Consultants group would be able to create issues in
these projects. This is too much access for HR Consultants. So this is not a desirable option.

172 - JIRA Administration Part 1

 Option 2 – use group to update new scheme:
1.  The Project Administrator requests JIRA Administrator to make the change.
2.  The JIRA Administrator creates the HR Consultants group and adds each consultant to
this group.
3.  The JIRA Administrator copies the Default Permission Scheme to create a new HR
Permission Scheme.
4.  The JIRA Administrator updates the HR Permission Scheme and adds the HR
Consultants group to the Create Issues permission.
5.  The JIRA Administrator associates the HR Permission Scheme with the Human
Resources project.
6.  The JIRA Administrator communicates and documents the changes.
The JIRA Administrator needs to create a new scheme and customize it so the Consultants
only get Create Issue permission in the Human Resources project. So this solves the problem
of Consultants having permissions in projects other than Human Resources.
Is this a good option?

173 - JIRA Administration Part 1

 Since requirements are often very specific (different teams, stakeholders, etc.), this sort of
situation could come up for many different projects. So the JIRA Administrator would have to
create many schemes and be involved in every requested change. Each project’s scheme
would need to be changed every time there’s a change in the requirement.
This incurs a lot of administrative overhead, is time consuming and does not offer much
flexibility. Also, having many schemes can incur a performance hit.
Maybe there’s a better way to address this issue…

174 - JIRA Administration Part 1

 The solution is to use project roles. In this scenario:
1.  The Project Administrator requests JIRA Administrator to make the change.
2.  The JIRA Administrator creates the Consultants Project Role.
3.  The JIRA Administrator copies the Default Permission Scheme to create a new General
HR Permission Scheme.
4.  The JIRA Administrator adds the Consultants project role to the Create Issues
permission in the General HR Permission Scheme.
5.  The JIRA Administrator associates the General HR Permission Scheme with the Human
Resources project.
6.  The JIRA Administrator communicates and documents the changes.
7.  The Project Administrator adds each consultant to the Consultants project role.
Initially there’s a bit of work for the JIRA Administrator to do. But once this is done, it’s a lot
easier each next time a request comes up. For example, when the HR Onboarding Project
Administrator asks for create issues permission for his consultants, the JIRA Administrator just
needs to associate the General HR Permission scheme with the project and that’s it. The HR
Onboarding Project Administrator then just needs to add the appropriate users/groups to the
Consultants project role. The JIRA Administrator sets up the Project Role once and adds it to
the scheme. Then each project can use it and define their own members. See next slide.

175 - JIRA Administration Part 1

 Here we see the power of roles and schemes. You use roles in schemes. Project roles are
global – they can be assigned to any scheme. Then you share the schemes among projects.
By assigning the Create Issues permission to a project role (Consultants), whoever has that
role in a particular project, will get that permission.
In this scenario, the Consultants project role is assigned to the Create Issues permission in the
HR Permission Scheme. Then that permissions scheme is used in multiple HR projects –
Human Resources, Onboarding, and Internal Training. In each of those projects the Project
Administrator has assigned different users or groups to the role. So the two consulting users,
Ravi and Sue, can create issues in the Human Resources project, the three consulting users,
Sam, Ava, and Nalini, can create issues in the Onboarding project and the Internal Training
Consultants group can create issues in the Internal Training project. (You can also have users
and groups in a project role.)
By using project roles you can use fewer permission schemes. Fewer schemes means better
performance. It also means you can share schemes and save a lot of administration work. It
takes requests that you would normally handle and puts them in the hands of Project
Administrators (assigning the particular users/groups to the role). That means you can focus on
the tasks that can’t be delegated to Project Administrators.
We’ll go into sharing schemes more in the next module.





176 - JIRA Administration Part 1
 For example, if your organization requires all software development issues to be tested by a
Quality Assurance person before being closed, you could do the following:
1.  Create a project role called Quality Assurance.
2.  Create a permission scheme called Software Development, in which you assign the
'Close Issue' permission to the Quality Assurance project role.
3.  Associate the Software Development permission scheme with all software development
projects.
4.  For each software development project, add the appropriate Quality Assurance people
to the Quality Assurance project role.

177 - JIRA Administration Part 1

 Project roles are a flexible way to associate users and/or groups with particular projects. A
project Role is kind of a “bucket” that holds individual users or groups. The members of
project roles are users/groups who fulfill particular functions for a project.
Project roles can be used in many places including permission and notification schemes, issue
security levels, workflow conditions and comment visibility. They can also be given access to
issue filters and dashboards. But the core usage is for permission and notification schemes.
While you could assign permissions and notifications to users and groups directly, roles are
more flexible and sustainable.
Project roles are similar to groups, the main difference being that group membership is global
whereas project role membership is project-specific. Additionally, group membership can only
be altered by JIRA administrators, whereas project role membership can be altered by project
administrators. Using groups in schemes means a lot more work for the JIRA Administrator.
See https://confluence.atlassian.com/display/AdminJIRAServer070/Managing+project+roles.

178 - JIRA Administration Part 1

 Different people may play different roles in different projects — the same person may be a
leader of one project but an observer of another project. JIRA enables you to allocate
particular people to specific roles in your project. Project Lead, Default Assignee and Project
Administrator are project roles that are automatically created for all projects. These could be
different people or the same person as shown in the slide (more on this soon).
•  Project Lead — person who manages the project. Can be used as the 'Default Assignee',
and potentially elsewhere in JIRA (e.g. in permission schemes, notification schemes, issue
security schemes and workflow conditions). Who should be the Project Lead? The Project
Manager or the Lead Developer (for Software projects) are good candidates. It's often a
good idea to set the Project Lead to whoever is in charge of triaging new issues and then
set the Default Assignee to the Project Lead. Also the Project Lead and the Project
Administrator may be the same person.
•  Default Assignee — When a new issue is created, if an assignee is not specified, the
project's Default Assignee is used. Can be either the Project Lead, or Unassigned (the
default). In JIRA's general configuration, the setting ‘Allow unassigned issues’ is set to ON
by default. You can turn this off if you do not wish to allow unassigned issues.
•  Project Administrator – Can edit the project details i.e. name, description, avatar, and URL.
They can also edit the project lead – in many cases the Project Administrator and the
Project Lead may be the same person. But probably their most important responsibility is to
NOTES CONTINUED ON NEXT PAGE

179 - JIRA Administration Part 1

 NOTES CONTINUED FROM PREVIOUS SLIDE
edit project role membership. They can also change the project type, define project
components and versions and view, but not select nor edit the project’s. (Changing the project
category of a JIRA project requires JIRA Administrator global permission.) By default when a
project is created the jira-administrators group is assigned to the Project Administrators role.
The default permission and notification schemes are already configured to use this role.

180 - JIRA Administration Part 1

 The JIRA administrators define the project roles in JIRA Administration so all projects have the
same project roles available to them. Then Project administrators assign members to project
roles specifically for their project(s).

181 - JIRA Administration Part 1

 Project Roles allow JIRA Administrators to delegate power to Project Administrators. The
Project Administrator role can be assigned in one of two ways:
1.  In the project, the JIRA Administrator assigns a user or group the Administrators project
role.
2.  In the permission scheme for the project, the JIRA Administrator assigns the Administer
Projects permission to a Project Role or user or group, etc. The use case for this is where
you want the Project Lead and the Project Administrator to be the same person. (See next
slide.)

182 - JIRA Administration Part 1

 Why would you assign the Administer Projects permission rather than just assigning someone
to the role in the project? You’d do this when you want to make the Project Lead the Project
Administrator for many projects. The Project Lead and the Project Administrator are often the
same person. The Project Lead typically performs the tasks of a Project Administrator –
assigning people to roles, updating project details, etc. It also makes JIRA administration
easier and takes a task off the JIRA Administrator’s plate.
To make the Project Lead the Project Administrator, the JIRA Administrator gives the Project
Lead role the Administer Projects permission in the Permission Scheme used for the projects
this is to apply to. It could be the default permission scheme for all projects of a certain
application type. Or it could be a permission scheme set up for categories of projects e.g. all
Development projects.
Then when a project is created, JIRA will automatically assign the Project Lead (also assigned
when project is created) to the Project Administrator. Once this is set up there is no further
involvement by the JIRA Administrator so it cuts down on administrative overhead.

183 - JIRA Administration Part 1

 JIRA can notify the appropriate people when a particular event occurs in your project (e.g.
"Issue Created", "Issue Resolved"). You can choose specific people, or groups, or roles to
receive email notifications when different events occur. As a best practice, roles are the easiest
way to manage notifications.
•  Notification Scheme — the project's notification scheme determines who receives email
notifications of changes to issues in this project.
•  Email — specifies the 'From' address for emails sent from this project. Only available if an
SMTP email server has been configured in JIRA.
Please note, the default notification scheme for each project type is associated with all new
projects of the corresponding type by default. This means that if you have an outgoing (SMTP)
mail server set up, that email notifications will be sent as soon as there is any activity (e.g.
issues created) in the new project.

184 - JIRA Administration Part 1

 The JIRA Permission Helper can help you diagnose why a user can or cannot see a certain
issue.
1.  Choose System > Permission Helper.
2.  Enter the username of the user (leave blank for anonymous users), an issue key (for
example, an issue that the user can/cannot see) and the permission to check.
3.  Click Submit.

185 - JIRA Administration Part 1

 Summary - The main concepts of JIRA permissions revolve around Users, Groups, Global
Permissions, Permission Schemes and Project Roles.
•  Users are defined by having 'JIRA Users' global permissions. They can login and count
towards your JIRA license.
•  Groups are multiple users within your instance that need the same application permissions.
•  Global Permissions are system wide and are granted to groups of users. These are JIRA
Administrators, Browse Users, Create Shared Objects, Manage Group Filter Subscriptions,
and Bulk Change.
•  Permission Schemes is a set of users groups or project roles assignments for the project
permissions. A single JIRA project can only have one permission scheme. However, a
particular permission scheme can be used by a number of projects.
•  Project Roles are a flexible way to associate users and/or groups with particular projects.
Their main difference with JIRA groups is that they are project-specific while groups are
global across the JIRA application.

186 - JIRA Administration Part 1

187 - JIRA Administration Part 1
 Answers are on the next slide.

188 - JIRA Administration Part 1

 Answers:
1.  A
2.  A and C

189 - JIRA Administration Part 1

 Answers are on the next slide.

190 - JIRA Administration Part 1

 Answers:
1.  A, b, d, and e

191 - JIRA Administration Part 1

 As a best practice we advise the use of project roles within JIRA wherever possible to allow
the use of fewer permission schemes. Second only to custom fields these are a major cause of
JIRA systems degradation. To maintain simplicity it’s preferable to assign permissions to
project roles in permission schemes (use groups sparingly if at all).
You can choose to grant permissions to specific users, or groups, or roles - roles are usually
the easiest to manage.
Only assign permissions to project roles in permissions schemes, not users or groups.
Create schemes that are shared across similar projects e.g. Development, that have similar
requirements rather than unique schemes for every project. Having a unique set of schemes
for every project will incur too much administrative overhead in a large installation. We’ll be
looking at sharing schemes more in the next module.

192 - JIRA Administration Part 1

193 - JIRA Administration Part 1
 A chance for you to give feedback about the lab. What did you find interesting? Did you get
stuck? What did you learn?

194 - JIRA Administration Part 1

 An opportunity for you to ask questions.

195 - JIRA Administration Part 1

196 - JIRA Administration Part 1
 This is the location of the Atlassian’s headquarters in Sydney, Australia.

197 - JIRA Administration Part 1

198 - JIRA Administration Part 1
 In this module we’ll cover some of the most common scenarios with schemes that revolve
around whether to use custom schemes or share schemes with other projects. Specifically
we’ll look at:
•  Creating a project and sharing another project's configuration – If you want a project that's
based on the configuration of an already existing project, you create a new project with
shared configurations. This means you share all the schemes so any changes to a scheme
will apply to both projects.
•  Sharing a scheme between projects – Sometimes there will be a similar requirement
between projects. To meet this you could share just one scheme between the projects.
•  Editing a widely shared default scheme – Sometimes you may want configuration changes
to apply to ALL projects. But be careful as you might inadvertently edit a default scheme
without realizing all projects using it will be changed. Always backup a default scheme
before editing it.
•  Using a custom scheme for one project – Sometimes you need to have a scheme just for
one project because it has unique requirements. To do this you copy a scheme (a default
scheme or one from another project), associate it with a project and edit it for just that
project.
•  Using all custom schemes for one project – If you have a project that has unique
requirements for the whole project then you need all custom schemes. When you create a
NOTES CONTINUED ON NEXT PAGE

199 - JIRA Administration Part 1

 NOTES CONTINUED FROM PREVIOUS SLIDE
project, by default (if you don't select Create with shared configuration), it automatically
creates a fresh copy of the workflow, issue type, screen, and issue type screen schemes for
use just in that project. But the project uses the default permission, notification, and field
configuration schemes. You would need to copy these defaults and associate them with your
new project to get these custom schemes.

200 - JIRA Administration Part 1

 Schemes are probably one of the biggest source of confusion for somebody who is relatively
new to JIRA administration, but once you understand the core concept they are a great way to
reduce your administrative overhead while keeping your flexibility up.
A scheme is a container/collection of configuration items. For example, here you see an
example of an issue type scheme that is the default for Software type projects. It contains all
the default issue types for that type of project.
Recall that only JIRA Administrators can create and modify schemes and associate schemes
with projects.

201 - JIRA Administration Part 1

 There are many different types of schemes and each one behaves slightly differently. Every
project has:
•  a permission scheme
•  a notification scheme
•  a workflow scheme
•  an issue type scheme
•  a screen scheme
•  an issue type screen scheme
•  a field configuration scheme
You can also create an issue security scheme but there are none created by default in JIRA.
These let you control which user or group of users can view an issue. Be very careful of
creating these as they can have a significant performance impact on JIRA!

202 - JIRA Administration Part 1

 When you create a new project from a template, some of its schemes are copied from the
default schemes and are just for that project and some are shared with the default schemes.
This is the default behavior when you create a project.
The schemes that are copied from the default schemes and are unique for that project are the
Workflow scheme, Screen scheme, issue type scheme and Issue Type Screen scheme. The
default schemes that are shared are Permission scheme, Notification scheme and Field
Configuration scheme.
* Note that for Permission schemes, it varies depending on which JIRA application you are
using. All JIRA Core Business projects will share the Default Permission Scheme by default. All
JIRA Software projects will share the Default Software Scheme by default. And all Service
Desk Projects will actually get their own copy of the Service Desk Permission scheme.
Also all Service Desk Projects will get their own copy of the Field Configuration scheme. The
only default scheme that Service Desk projects share is the Default Notification Scheme.

203 - JIRA Administration Part 1

 In this case, the organization requires a project with custom schemes as the project has
unique requirements that are very different from all other projects. For example, permissions
need to be very restrictive, only a few people will be able to work with issues (create, edit,
etc.), and it will have a unique workflow, etc.

204 - JIRA Administration Part 1

 When you create a new project (using the default method), if you update any of the schemes
that are unique to that project, it will only affect that project and no other projects. The unique
schemes are the copied workflow, screen, issue type and issue type screen schemes.
However, when you create a new project (using the default method), if you update any of the
shared default schemes, it will affect all other projects using the default schemes! These are
the default permission, notification and field configuration schemes for Business and Software
projects and permission scheme for Service Desk. All new projects share these by default.

205 - JIRA Administration Part 1

 In the example we’re using here the Customers project requires all customized schemes
including the permission, notification and field configuration schemes which are, by default,
shared with the default schemes.
To accomplish this, the JIRA Administration will need to copy these default schemes and
associate the copies with the Customers project.
Having unique schemes for a project gives the JIRA Administrator a great deal of control over
their project however it means more maintenance!

206 - JIRA Administration Part 1

 Sometimes requested changes are too specific and only apply to a single project. In those
cases we most likely need one project specific scheme.
If there is a very specific need you might need to limit that scheme to this project. In our case
it’s the Permission Scheme.

207 - JIRA Administration Part 1

 To create the permission scheme that is unique for the X Cloud app project the JIRA
Administrator would need to:
1.  Copy either the default software permission scheme or the permission scheme created for
all Development projects.
2.  Update the Browse Projects permission in the new permission scheme so only project
members can browse the project.

208 - JIRA Administration Part 1

209 - JIRA Administration Part 1
 Sometimes you have projects with similar requirements so you can share the project schemes.
The Human Resources project has been configured just the way Human Resources wants it.
Now this configuration can be reused in other Human Resources projects. In this case the
Payroll project has the same requirements as the Human Resources project. So when the JIRA
Administrator creates the Payroll project, they select Create with shared configuration and
select the Human Resources project to use that project's schemes. This means all the
schemes will be shared between these projects.
Note that when you're sharing schemes, any change to the scheme will affect all the projects
using that scheme!

210 - JIRA Administration Part 1

 Another example: We’ve added a new Person issue type and created the HR Issue Type
Scheme. All new HR projects should be sharing this scheme so they can use the Person type.

211 - JIRA Administration Part 1

 The IT, Legal and Marketing projects have requested they get fewer notifications when issues
are assigned and updated. To accomplish this the JIRA Administrator has:
1.  Created a new notification scheme, called Minimal Notification Scheme, by copying the
Default notification scheme.
2.  Updated the new Minimal Notification scheme, cutting down who gets notifications for
Issue Updated and Issue Assigned.
3.  Used the new Minimal Notification Scheme in the IT, Legal and Marketing projects.
Note that any changes to the Minimal Notification scheme will affect all the three projects that
share it!

212 - JIRA Administration Part 1

 Sharing Schemes reduces Administrative Overhead. Generally you want to avoid having too
many schemes as that requires a lot of work to maintain. You want to share schemes as much
as possible where you have a reasonable belief that the shared configuration will stay in sync.
Even if things go out of sync, most schemes can be easily copied and reverted if necessary.
Do what you need to do to meet your business needs but try to re-use schemes and
workflows. The more that are standardized across the whole system, the less features there
are and fewer screens & fields to be loaded every time an issue is created, edited or closed.
This will mean better performance. Having many schemes, especially if you have different ones
for every project, can cause poor performance. For example, a large enterprise installation with
hundreds of projects and with schemes for every project will definitely see a performance hit.
Reducing the number of schemes will improve performance. Having good governance over the
creation of schemes becomes more important as your JIRA instance grows. Too many
schemes means too much administrative overhead, too much complication and poor
performance.
Another advantage to sharing schemes is consistency – Users will know what they get. For
example, Developers switching to a different development project will have the same
permissions, will get the same notifications, will see the same issue types, etc. This makes it
easier for them.
The disadvantages with shared schemes are that you have some limited flexibility and as
NOTES CONTINUED ON NEXT PAGE

213 - JIRA Administration Part 1

 NOTES CONTINUED FROM PREVIOUS SLIDE
changes have an impact on all projects that use shared schemes a lot of stakeholders (Product
Managers, etc.) will need to be involved with every change.
The advantages to custom schemes is that they can satisfy very specific requirements and
modifying these schemes doesn’t impact other projects. Limiting to a Scheme to one project is
certainly not such a big problem in smaller organizations, but consider scaling when you do
this. It should be the exception. The disadvantages of having too many custom schemes are
great – administrative overload and poor performance.
It’s a balance! If projects are too specific and modifying an existing scheme would have too
much impact on other projects, create a new Scheme – otherwise try to reuse a Shared
Scheme.
Keep it simple, organized and documented or you’ll end up with a mess, too much work, and
bad performance.

214 - JIRA Administration Part 1

 Have as few schemes as possible and share them. This is the key to scaling JIRA.

215 - JIRA Administration Part 1

 Share schemes between similar projects types or business areas (Departments) in your
organization. Align shared schemes with project categories if it meets your business needs.
They are not technically connected but you can use categories as a logical organization. In this
example, Application Development has a set of schemes that are shared for all Development
projects. They can use shared schemes since the general requirements (process, data etc.) are
basically the same. This makes things easier to manage in a growing instance, and especially
in a large organisation. It makes it much easier when you set up a new project of Type
Development. You can ensure that each development project has the same schemes and so
each development project works in an expected way, which follow your organisational
processes. This means that everyone will know how to use JIRA to support the expected
processes for that project type and helps to get the same project outcomes.

216 - JIRA Administration Part 1

 A few more best practices for schemes:
•  It’s your responsibility as a JIRA Administrator to create strong governance around limiting
schemes.
•  Keep the schemes as non-specific as possible. Use roles not users or groups.
•  Follow a consistent naming convention - Include project name or indicate business area.

217 - JIRA Administration Part 1

 Keep a trail of why changes were made and what changes were made to help inform you and
your users later down the line. You’re not documenting the schemes themselves but changes
made and who did them.
Communicate the changes to your users to ensure that they are fully aware of what is
happening and won’t be surprised or possibly upset if a change is made when it affects what
they do and what they are used to.
Test with copies of the Scheme - ideally in a test or staging environment. This is especially
important for Workflow schemes where changes you make to a scheme may not be able to be
undone easily. This is because the issues themselves are migrated.
To communicate changes to all stakeholders, including users and Administrators, use some
sort of pubic announcement. For example, the Public Announcement Service for JIRA &
Confluence add-on that’s available on the Atlassian Marketplace. This allows you to set
groups/roles, use scheduling, etc. (It is unsupported by Atlassian.)

218 - JIRA Administration Part 1

 If you delete a project, all the unique schemes created for that project remain, they are not
automatically deleted. This is because they may be shared with other projects. Also you may
want to reuse them in another project.

219 - JIRA Administration Part 1

 Answers are on the next slide.

220 - JIRA Administration Part 1

 Answers:
1.  A, C, and E

221 - JIRA Administration Part 1

 Answers are on the next slide.

222 - JIRA Administration Part 1

 Answers:
1.  D and C could be true if project A was using a customized copy of the Default
Notification Scheme that no other project was sharing.

223 - JIRA Administration Part 1

224 - JIRA Administration Part 1
 Best Practices
Share Schemes whenever possible between similar projects or business areas – align with
your project categories.
The key to scaling JIRA is to have as few schemes as possible and share them!
Use roles to keep the schemes as non-specific as possible. Don’t use users or groups in
schemes as it makes them too specific.

225 - JIRA Administration Part 1

226 - JIRA Administration Part 1
 A chance for you to give feedback about the lab. What did you find interesting? Did you get
stuck? What did you learn?

227 - JIRA Administration Part 1

 An opportunity for you to ask questions.

228 - JIRA Administration Part 1

229 - JIRA Administration Part 1