Welcome to the preparation course for the ACP-100 exam.

This course will help you

become an Atlassian Certified Professional Jira Administrator for Data Center and Server.

References throughout to Server are generally applicable to Data Center. You can
prepare using Jira on either a Server or Data Center implementation.

1-<Jira Administration for Data Center and Server>

2-<Jira Administration for Data Center and Server>
 Here’s a brief overview.
1. In the first few slides, we will review the target audience and expectations, so you
can gauge if you’re ready and if you possess the suggested years of experience.
2. The bulk of the course is diving deep into main topic areas (each one is a module in
this course) and the objectives underneath of them.
3. There are examples at the end of each objective to test your understanding. You’ll
have to think through configurations and troubleshooting questions.

The course is not meant to be absorbed in one sitting, from beginning to end. Rather, you
can go through a few objectives at a time and identify areas of strength and weakness.
Right now, you may not know what you don’t know. But this course will help you figure
that out so you can focus your preparation. You can make a study plan – either on your
own or in a group – of the topics that you need to explore further and ideally experiment
in a lab environment. It will help you break down your exam preparation into concrete
steps.

3-<Enter course
3-<Jira name in Notes
Administration master>
for Data Center and Server>
 The target audience has at least 2-3 years experience as a Jira Administrator. Real world
experience is vital since the exam is based on typical scenarios that a Jira administrator
would likely have seen, while working daily in the system. It would be hard to study for
this exam unless you have already had significant exposure and experience with Jira
Administration. We recognize that, for a lot of administrators, managing Jira is just one
part of their job. This doesn't mean that you will not be able to pass the exam, if you
have less than a year of of experience working as a Jira Administrator. But it will probably
be much more challenging for you.

The topics are structured around the persona of the Jira Administrator. That means they
focus on the knowledge and skillset of the candidate that we expect can pass this exam
and serve as a proficient Jira Administrator. They cover the kinds of tasks we expect the
Jira administrator to do in his or her day-to-day job. They are grouped into objectives, or
large logical content areas, with sub-points and important things to know within each
area. But this preparation course doesn’t cover every single bit of knowledge that you
should know for the exam. And it doesn’t replace real-world experience. Keep in mind
that you won’t know which content an exam question tests for, and the topics are often
combined.

4-<Jira Administration for Data Center and Server>

 The candidate is not expected to be a business analyst. But they should be able to read
and understand business requirements. Based on given requirements or a scenario, they
need to know how to design and implement the optimal Jira configuration, modify it, or
troubleshoot problems with an existing setup. This means they have an excellent
understanding of all the Jira project schemes, like workflows, permissions, and
notifications.

We have a special note here about troubleshooting-type questions that you will see on
the exam. Troubleshooting questions describe the problem and then ask for a possible
root cause or an appropriate solution. Sometimes the fix is quick, but sometimes it might
require you to invest time to redo a configuration so it’s scalable for the future. Here is
where real-world experience is so important and why book-learning alone would be
insufficient. You need to know how to keep Jira healthy because you grasp how your
choices affect performance, scalability, and day-to-day manageability.

5-<Jira Administration for Data Center and Server>

 Many topics are agnostic between Jira Cloud and Jira Server, but the ACP-100 exam is
based on Jira Server, so you will find server-specific questions only. If you currently work
primarily in a Cloud environment, make sure to spend time with Jira Server
documentation and a test environment.

The exam does not include any knowledge of tasks and functions typical for a System
Administrator, Database Administrator, Email Administrator, and LDAP Administrator.
But the candidate should be familiar with what those roles do, so they know who to
coordinate with, within their organization. So, for instance, you ought to be aware that
while configuring mail handler functionality, you may need to work with your email
administrator. Or, to connect a user directory, you may need to work with an LDAP
administrator.

6-<Jira Administration for Data Center and Server>

 The candidate is expected to regularly consult with Atlassian resources and engage with
the Atlassian community to support their team in implementing Jira best practices. This
includes the Atlassian Community platform, Atlassian Jira system for bug reports and
feature requests, Atlassian Marketplace, and Atlassian User Groups. You should be
engaging with these communities and resources regularly to learn best practices and to
improve your Jira Administration practices as a result.

With respect to the Marketplace, the candidate is not expected you to know the details
of apps available for Jira, but you do need to know how to evaluate them, and how to get
support for them. For example, understand what “Top Vendor” means with respect to an
app.

7-<Jira Administration for Data Center and Server>

 Ultimately, this course aims to help you gain confidence in becoming an Atlassian
Certified Professional Jira Server Administrator.

8-<Enter course
8-<Jira name in Notes
Administration master>
for Data Center and Server>
 This is our first module – Advanced User Features.

A Jira administrator is also a Jira product advocate in their organization. You are
expected to help end-users. So you should know everything about Jira that a power user
would know. This module covers things like writing advanced JQL queries, creating filter
subscriptions, performing bulk operations, and CSV imports.

9-<Jira Administration for Data Center and Server>

 This module contains 4 objectives, as shown.

A quick note about the format of this course. Each module will have a slide like this one,
which lists all the objectives within that module, without reading through them. The
objectives are listed for the sake of completeness. But it will also help you gauge the
amount of content contained in each module, so you can divide your study appropriately.
We follow a consistent structure for each objective and a numbering scheme that
includes the module number followed by the objective number. Let’s get started.

10-<Jira Administration for Data Center and Server>

 Given a business requirement, you should be able to create, translate, critique, and
optimize JQL queries. As a Jira Administrator, it’s expected that you’ll help users with
writing and improving or correcting their JQL queries. There is a lot to know about the Jira
Query Language. So if you’re not proficient in using advanced search, you should review
Atlassian's JQL tutorials and documentation.

11-<Jira Administration for Data Center and Server>

 JQL is used throughout Jira; in searches and board configurations, as well as queues and
SLA settings of Jira Service Desk. Jira administrators are expected to be JQL masters. Let’s
review the syntax. There are:
1. operators
2. values
3. functions
4. and of course, fields.
5. You should be able to recognize Jira’s system fields in a query – such as issue type,
status, priority, and others,
6. and be able to differentiate them from custom fields.

12-<Jira Administration for Data Center and Server>

 Certain operators
1. are only appropriate to certain field types and you should study which ones are
which.
2. For example, you would use equals, not equals, greater than and less than with
numeric fields
3. The Contains operator (which is the tilde character) with text fields.
4. In and not in for select list fields, radio buttons and checkboxes
5. Is and Is Not
6. With either NULL or EMPTY to check for the presence of a value.
7. Know the correct placement of NOT. For example, “NOT status changed”
8. Both the WAS and CHANGED operators search for value changes but there is a
difference in the search of change history
9. These operators only apply to certain fields: namely, Assignee, Fix Version, Priority,
Reporter, Resolution, and Status.
10. And they take optional predicates such as FROM, TO, BY, BEFORE, AFTER and DURING

13-<Jira Administration for Data Center and Server>

 You should be well-versed in all the native JQL functions
1. But especially those related to date searches such as
2. now()
3. startOfDay(), endOfDay()
4. As well as those for start and end of week, month, and year
5. Be sure you understand fully how to use optional increments of plus or minus a
certain number of days, weeks, months, etc.
6. With or without the use of the time unit qualifier (such as “d” for days).
7. And that it defaults to the natural period of the function, if it is omitted.
8. For example, to find issues due by the end of tomorrow, you would write “due <= 1d”.

14-<Jira Administration for Data Center and Server>

 You should know how to construct complex queries and evaluate the results.
1. Especially how to evaluate the results returned by multiple clauses
2. How to group multiple queries
3. and nest filters
4. How to evaluate the order of operations when multiple clauses are joined together
5. with the Boolean operators AND versus OR
6. Be vigilant about the use of parenthesis, for both readability and results.
7. The correct placement of parenthesis can greatly affect the results returned by a JQL
query

15-<Jira Administration for Data Center and Server>

 You should have an idea of what is considered best practice with respect to JQL and why.
1. Know the principles behind building efficient and robust queries, so you can apply
them to different use cases.
2. Understand the impact of JQL on overall system performance
3. Think of readability, especially long queries with multiple clauses and parenthesis
4. And limit the scope of a search. For example, it might be best to query a few select
projects instead of querying the entire Jira instance.

16-<Jira Administration for Data Center and Server>

 Also keep in mind the maintainability of saved filters. Can a filter be written in such a
way that it can accommodate future changes? For example:
1. It might be better to use the functions “membersOf()” or “currentUser()” instead
individual usernames
2. Or the functions “subTaskIssueTypes()” and “standardIssueTypes()” instead of listing
issue type names, in situations where new issue types are being added into Jira.
3. Or use the special “category” field which will return all issues in all projects listed
under that category, instead of listing individual project names. These are just
examples and there are others.

17-<Jira Administration for Data Center and Server>

 On the exam, you’ll encounter many JQL statements. You might see them in the question
itself and be asked to evaluate it; whether it returns too few or too many results, or
whether the query itself is invalid or inefficient. Or you may be given business
requirements and asked to determine which of the JQL statements – listed in the
answers – will meet those requirements. Here is just one example of a complex query
with multiple clauses using AND and OR Boolean operators, and various fields, functions,
and operators. Inspect the query. Right away, you might be asking yourself some
questions:
1. Does it need parenthesis to perform the order of operations correctly?
2. Is it returning the right results?
3. Is it efficient?
4. Is the date increment correct?
5. One character can make a huge difference in a JQL query. Read slowly and carefully.

18-<Jira Administration for Data Center and Server>

 Demonstrate the benefits and best practices for configuring group subscriptions. You
need to know them, so that you can assist end-users.

19-<Jira Administration for Data Center and Server>

 But first, let’s distinguish
1. Personal versus group subscriptions. Personal means it is running just for you. Anyone
can create them. Group subscription means that a single user will create it, but the
results will be sent to the group subscribed.
2. The “Manage group filter subscriptions” global permission is required to create and
delete group filter subscriptions.
3. You should know the configuration options for setting up a filter subscription
4. Including the option to email the filter, even if there are no issues found
5. And the scheduling options
6. Also, be aware of potential performance implications, such as sending large
subscriptions very frequently to many users. This can also impact the mail service.

20-<Jira Administration for Data Center and Server>

 You also need to know what email content is generated as a result of the subscription.
1. It will include the same content that would be returned if the subscription's query
was running in the Issue Navigator
2. The results are relevant to the user for whom the subscription is being run. It is “as if”
that user were running the query himself and viewing the search results.
3. This means that the content delivered via email will respect permission settings at
the project level
4. And security levels, if issue-level security is configured.
5. Bottom line, different users may receive different results via email for the same filter,
depending on their project and issue permissions.

21-<Jira Administration for Data Center and Server>

 So let’s look at this concrete example. Let’s say that the the group “developers” is
subscribed to a saved filter with this JQL query. What will be the subscription content?

1. Recipients will only receive their own assigned issues because the subscription runs
relevant to each recipient for whom it is being run
2. Recipients must have Browse Projects permission in the CERT project
3. And recipients must have access to the Security Level of any issues where issue-level
security is enabled
4. It also depends if zero results are found for that recipient and the setting “Email this
filter, even if there are no issues found” is enabled
5. Of course the subscription will only be sent to active user accounts

22-<Jira Administration for Data Center and Server>

 Next, you should be able to describe the results and implications of a bulk change
operation. You need to know the benefits, limitations, and implications.

23-<Jira Administration for Data Center and Server>

 Bulk change means making changes to multiple issues at once.
1. This requires the Bulk Change global permission.
2. The global permission, however, does not grant more privileges than a user would
normally have on an individual issue. Namely, Bulk operations respect the underlying
project and issue permissions. So if a user cannot delete individual issues in a project,
the user cannot delete them in bulk either. The option to bulk delete will not be
available for the relevant issues.
3. Assuming the necessary permissions are granted, it allows users to see and use the
Bulk Change action on a set of issues in Issue Navigator.
4. And to run CSV import. More on this in a later module.
5. Bulk change should be appropriately restricted, because it allows the manipulation or
deletion of potentially hundreds of issues.

24-<Jira Administration for Data Center and Server>

 The execution of these operations is nuanced.
1. The 4 main steps are choosing the issues, choosing the type of operation, the
operation details, and then clicking Confirm.
2. There are six types of operations:
3. Edit Issues
4. Move Issues
5. Transition Issues
6. Delete Issues
7. Watch Issues
8. And Stop Watching Issues. Some operations have additional steps like field or status
mapping. Note also that when editing some fields you can add to existing values,
clear values, replace all, or find and remove.
9. Finally, be aware that you can suppress notifications by unchecking the option “Send
mail for this update” for a bulk change operation, if desired. This option is available
only for Jira administrators.

25-<Jira Administration for Data Center and Server>

 You should also understand the expected results of a bulk operation.
1. For example, once the operation is completed, issues may drop out entirely from the
filter in Issue Navigator from which you chose the operation. Because the updated
issues may no longer match the filter criteria.
2. Also, what happens to issue keys when an issue is moved to another project? The
moved issue will still be associated with its initial key, so it’s still possible to search
on that issue key. However, the issue will have a new key based on the target project.

26-<Jira Administration for Data Center and Server>

 You might ask yourself, What could possibly go wrong?
1. You cannot Bulk Delete if you do not have Delete permissions in individual projects.
But if you do, you can still do a lot of damage accidentally on potentially thousands
of issues.
2. And there is no simple “undo” possible.
3. Issues may not transition due to workflow inconsistency
4. For example, if there is a validator present on the transition
5. Or if the issues are not in a state that can be transitioned, i.e. there are no outgoing
transitions from the current state.
6. Another potential problem is users not being able to use bulk edit operation on
Closed issues. The status property “jira.issue.editable” may be set to false.
7. And of course, the user may lack the necessary permissions, for example to set the
Due Date, if they do not have the Schedule Issues permission.

27-<Jira Administration for Data Center and Server>

 Let’s look at an example here of a scenario that involves good knowledge of bulk
operations. User Tom wants the ability to transition hundreds of old issues to Closed.
What are some relevant configurations involved for him to be able to do so?
1. The obvious one is that Tom needs the Bulk Change global permission.
2. He also needs the relevant project permissions; Browse Projects, Transition Issues,
and perhaps also Resolve Issues or Close Issues permission, depending on workflow
configuration
3. The issue must be in the appropriate status or there must be an available transition
that goes to Closed
4. There may be workflow conditions
5. Perhaps based on groups or project roles
6. Or validators preventing the transition from continuing

28-<Jira Administration for Data Center and Server>

 Finally in this module, you should be able to describe the pre-requisites for and the
results of a CSV import. CSV (or comma-separated value) files are text files that
represent tabulated data for use in spreadsheets and databases.

29-<Jira Administration for Data Center and Server>

 First, let’s make a distinction between end-users versus administrators performing a CSV
import.
1. End-users
2. Can create issues through the Issue Navigator
3. If they have the Create Issue project permission for the relevant projects
4. and the Bulk Change global permission
5. On the other hand, Jira administrators
6. can go through external system import in the system administration menu
7. To use the CV file import option from the JIRA Importers plugin, which is bundled with
JIRA
8. It provides access to more CSV import options and advanced import functionality. The
rest of the slides in this section focus on the Jira administration side.

30-<Jira Administration for Data Center and Server>

 On the exam, you might see a portion of a CSV file and then be asked to predict the
results. A successful import depends on the formatting of the source file.
1. Structure and setup of the CSV import file is important.
2. When you create the CSV file, make sure that all fields are separated by commas
3. And that any piece of content (including commas and new lines) is enclosed in quotes.
4. Each CSV file must have an unpunctuated header row with a Summary column.
5. You must delimit columns and fields with commas.
6. Use double-quote marks (") in the CSV file to capture data that spans multiple lines.
7. Use double-quote marks around a section of text to treat special characters in that
section literally
8. Try running several imports to see the errors and results. CSV import files require attention to
detail.

31-<Jira Administration for Data Center and Server>

 The import allows for data mapping.
1. You can use the import wizard to map individual fields and field values and the
correct parameters during the import
2. This includes users, projects, fields, and dates
3. CSV import on Jira Server does not enforce status mapping
4. Finally, you will be given the option of saving a CSV configuration file, which contains
the settings you configured while running through the CSV file import wizard. This is
especially useful during testing.
5. And remember that it’s always a best practice to test CSV file import on a test Jira
server first – before performing the import on a production system.

32-<Jira Administration for Data Center and Server>

 Are there potential problems?
1. Yes, invalid project keys. You can import issues from your CSV file into different JIRA
projects through a CSV file import. The project name and key data is the minimum
JIRA project data required for importing issues from a CSV file into specific JIRA
projects. So you must ensure accuracy.
2. Another is incorrect date formatting. You must use syntax that complies with the Java
SimpleDateFormat.
3. And problems with usernames. With respect to this one, if you are importing a
username-based CSV field (e.g. Reporter or Assignee) and you do not select the Map
field value checkbox for this field in the previous step of the CSV file import wizard,
then the importer will automatically map imported usernames from the CSV file to
(lowercase) Jira usernames. Regardless of whether or not you select the Map field
value checkbox, Jira will automatically create usernames based on the data in your
CSV file if they have not already been defined in Jira. If you are using External User
Management, the import process will not be able to create users; instead, the
importer will give you a list of any new users that need to be created. You will need to
create the users in your external user repository before commencing the import. If you
have a user-limited license (e.g. personal license), and the number of required users is
larger than the limit, then the import will be stopped.

33-<Jira Administration for Data Center and Server>

 Let’s look at this example. What is the result of the import file shown below?

34-<Jira Administration for Data Center and Server>

 The first line will create issue TT-1.

35-<Jira Administration for Data Center and Server>

 The second line will set votes to 7 and add two labels on TT-1

36-<Jira Administration for Data Center and Server>

 The third line will change the summary on TT-1.

37-<Jira Administration for Data Center and Server>

 The fourth line will create issue TT-2 with two labels.

38-<Jira Administration for Data Center and Server>

 The fifth line will remove those labels with a special marker <<!clear!>>. You can import
issues from the CSV file into different Jira projects by adding two columns to your CSV file
with the headings "Project Name" and "Project Key“ and ensuring that every issue in the
CSV file contains the name and key in these columns for the corresponding Jira projects.

39-<Jira Administration for Data Center and Server>

 Our next module is Configuring Global Settings, Layout, Design, and User
Communications. We will look at the type of things you should consider when preparing
for exam questions on this topic.

40-<Jira Administration for Data Center and Server>

 It contains 4 objectives.

41-<Jira Administration for Data Center and Server>

 Modify Jira configuration settings to match the organization's requirements (look and
feel, logo, website links in the application navigator, and default language).

42-<Jira Administration for Data Center and Server>

 This means you should know the various options for branding Jira.
1. How to modify the look and feel
2. That it’s possible to change the interface colors
3. And to update the Jira logo to your own
4. Or add a favicon.
5. But you can’t update font styles or sizes.
6. You also have customization options for languages
7. And time formats.
8. Focus only on what’s available through the Jira interface – without changing any
system files.

43-<Jira Administration for Data Center and Server>

 There are other areas to customize and troubleshoot.
1. For example, the announcement banner
2. Might be missing the end html tag.
3. In the application navigator
4. A link may not appear as expected if it was set to be “hidden”
5. And you can restrict viewing of links to members of user groups.

44-<Jira Administration for Data Center and Server>

 You just installed a new Jira. What are the typical things you may wish to configure to
reflect the company brand?
1. Company logo
2. Favicon
3. and colors are typical one-time configuration settings used to brand an instance.

45-<Jira Administration for Data Center and Server>

 You should be able to judge the appropriate content for the system dashboard,
user/team dashboards, and filter columns for an organization.

46-<Jira Administration for Data Center and Server>

 Let’s begin with dashboards.
1. The audience determines the best content. So you should be able to distinguish
content (namely, the gadgets) relevant for a system dashboard versus a team
dashboard versus a user or personal dashboard.
2. System Dashboard should contain content of general use for everyone at your entire
company, especially infrequent or inexperienced users that might not set up their
own dashboards for a long time, if ever. Many users stay with this single System
Dashboard for a long time until they become familiar with creating their own filters
and dashboards, so it’s good to give them the kind of content that most users are
likely to want to see.
3. Team dashboards usually focus on project-specific information.
4. Personal dashboards usually focus on reported, watched, and assigned issues.
5. Filter Results, Issue Statistics, and Two-Dimensional Filter Statistics are useful for all
types of dashboards. You should definitely know these three and all other typical
gadgets and their settings.

47-<Jira Administration for Data Center and Server>

 With respect to filter columns:
1. Jira administrators can configure the default columns that appear in Issue Navigator
for all internal users who do not have personal column filters defined. Namely, you
can set and change the columns for all users who have not set their own defaults.
2. This appears in the Columns dropdown on the top right of the issue table, when
looking at List View (as opposed to the Detail View) of the Issue Navigator.
3. If you are a Jira Administrator, you will also see the System tab, where you can
change the columns
4. Users can have their own defaults
5. Or can restore defaults to the system defaults
6. Each saved filter can have its own column configuration

48-<Jira Administration for Data Center and Server>

 As an example, let’s review a few gadgets and decide if they would be appropriate on a
system, team, or user dashboard. Just keep in mind that these are going to be general
considerations, and the answer really depends on the business scenario presented on an
exam question.
1. The Introduction gadget is most appropriate for the system dashboard which is
visible to all new users and thus likely the less experienced one. They may benefit
from some basic information about this Jira instance. The text comes from the
General Configuration page, so it contains static information. Hence, it doesn’t make
sense on a user or team dashboard.

49-<Jira Administration for Data Center and Server>

 The Assigned to Me gadget might be appropriate for both the system dashboard, for the
same reasons as above, but also on a user dashboard containing other information that
is specific to that user, like their reported issues, or watched issues. But probably not on
team dashboards. They will generally show issues assigned across all the team
members, shown by various statistics.

50-<Jira Administration for Data Center and Server>

 Therefore, issue statistics make sense on a team dashboard, like all the team’s issues
displayed by Status, By Priority, By Fix Version(s), By Issue Type, etc. But also, such slices
of data might be useful for a single user, as well, if the underlying saved filter returns just
that person’s issues. So Issue Statistics gadget could also be appropriate on a user
dashboard. Generally, such slices of data are not useful on a system dashboard
especially as the instances grows in the number of projects, issues, and users.

51-<Jira Administration for Data Center and Server>

 The same logic applies to a Two-Dimensional Filter Statistics gadget. It would mostly
likely fit for user and team dashboards, but not a system dashboard.

52-<Jira Administration for Data Center and Server>

 The Activity Stream gadget may be appropriate for all three types of dashboards,
depending on the use case. It can show the activity stream for an entire instance, or just
for a single project that the team works on, or whatever activity a single user wants to
see in their dashboard feed.

53-<Jira Administration for Data Center and Server>

 Objective 3. Determine appropriate methods for communicating information to users.

54-<Jira Administration for Data Center and Server>

 The audience is once again important.
1. Here, the content you need to communicate determines the audience (the users) with
whom that information will be shared and how.
2. When users are online, the Announcement Banner is good to relay critical system
information such as outages or planned down time. It can be communicated
3. for all users
4. or just logged-in users.
5. It is also possible to send email feature regarding more targeted information
6. to members of user groups
7. and members of project roles in projects that you select. This is useful to
communicate changes to all the intended recipients whether or not they are
frequently logging into Jira

55-<Jira Administration for Data Center and Server>

 As an example, let’s see which communication method is best in the following three
scenarios.
1. Planned upgrade of a Jira instance used by customers.
2. This is probably a good candidate for the announcement banner in advance of the
outage. The fact that customers use it is a very strong reason to use the banner
versus sending email.
3. Changes to workflow shared by 2 internal projects
4. This is a good candidate for the Send Email functionality, since the changes will
impact only a couple projects. You can send email to all users of the two projects, or
just project roles.
5. Enabling a password policy.
6. This depends and you might need some more information to decide. Password policy
is only enforced as passwords are changed. So an announcement banner might
suffice to tell users when the change will happen, and then update it to remind them
to do so. If you plan to use some method to forcibly change the users’ passwords to
something they won’t know (thereby requiring them to reset it to get back in), you
might want to send an email beforehand with a warning. Of course, these are just
some of the scenarios and considerations. In the exam, you will be provided more
details so you can determine the appropriate method for communicating information
to users.

56-<Jira Administration for Data Center and Server>

 Determine which global settings to modify to meet provided business requirements
(attachment options, issue links, time tracking, subtasks, white list, and general
configuration).

57-<Jira Administration for Data Center and Server>

 With respect to attachments:
1. Administrators can set the total upload size limit
2. Enable the creation of thumbnails of image attachments
3. And Enable ZIP support. And all 3 assume that the “Allow Attachments” setting is set
to ON.
4. Otherwise, attachments can be disabled in the system as a whole.
5. Assuming that attachments are enabled, then Create Attachment permission is
needed within each project. We will discuss permission in the next module.

58-<Jira Administration for Data Center and Server>

 With respect to issue linking:
1. Links are defined globally
2. with a name, outward link description, and inward link description.
3. Know that JQL query results might be impacted if they are changed
4. Issue linking can be deactivated in the system as a whole.
5. Assuming that Issue Linking is enabled, then users need “Link Issues” permission in
each project to be able to use it.

59-<Jira Administration for Data Center and Server>

 With respect to time tracking:
1. Know the settings of working hours per day and days per week
2. And Time display format
3. Administrators can set the default unit for time tracking if one is not entered by the
user
4. And time tracking can be deactivated in Jira as a whole
5. Assuming that Time Tracking is enabled, then users need the “Work On Issues”
permission in each project to be able to enter estimates and log time.

60-<Jira Administration for Data Center and Server>

 With respect to sub-tasks:
1. Jira administrators can add new sub-task issue types
2. Translate them
3. Or disable them all-together
4. And to manage which sub-tasks are used in a project, you add or remove them in the
relevant Issue Type Scheme
5. So to use sub-tasks in a project, they must be enabled in Jira and be part of the
project’s issue type scheme.

61-<Jira Administration for Data Center and Server>

 And finally, you should be very familiar with all the settings in Jira’s General
Configuration page.
1. Because global settings impact every user. Among others, these include:
2. Voting set to ON or OFF
3. Watching set to ON or OFF
4. Whether unassigned issues are allowed in any Jira projects
5. Publish sharing – which allows users to share dashboards and filters with the public
6. User email visibility
7. And Comment visibility. You can enable/disable comment and worklog visibility
based on groups and project roles. We will discuss these last three options a lot more
in module 5 on Authentication and Security.

62-<Jira Administration for Data Center and Server>

 As review for this objective, we will combine knowledge from this module as well as the
next module on project permissions. Exam question don’t specify which objective is being
tested. So you must be able to analyze and evaluate the context provided in the exam
question itself, in order to identify all the configuration settings that may be involved,
and then choose the appropriate one from among them.

Let’s say that the business requirements state that users need to be able to perform
certain actions listed. What are the relevant settings that you should check, configure,
and/or troubleshoot for each one? Let’s look at them.

63-<Jira Administration for Data Center and Server>

 1. To attach files, the global setting to Allow Attachments must be set to ON. And users
need “Create Attachments” permission in the relevant project.
2. To link issues, the global setting for Issue Linking must be activated. And users need
the “Link Issues” permission in the relevant project.
3. To log time on issues, the global setting for Time Tracking must be activated. And
users need the “Work On Issues” permission in the relevant project.
4. To create sub-tasks in a particular project, sub-tasks must be enabled in the system,
the project’s Issue Type Scheme must contain Sub-tasks issue types, and users need
the ”Create Issues” permission. So how do you choose between the global
configurations and project settings?
5. Look for context clues about whether the user can perform that action in a different
project. For example, if a user can attach in project1 but not project2, we know that
Allow Attachments is already set to ON. Otherwise, he couldn’t attach at all, and
neither could anyone else.

64-<Jira Administration for Data Center and Server>

 Our next module is Application Access, Project Access and Permissions. This is a
fundamental area of understanding for the Jira Administrator.

65-<Jira Administration for Data Center and Server>

 This module has 5 objectives.

66-<Jira Administration for Data Center and Server>

 Determine the appropriate use of application access, groups, roles and permissions. This
is a broad topic.

67-<Jira Administration for Data Center and Server>

 Application Access
1. allows a user to login and access a particular Jira product (Jira Software, Jira Core, or Jira
Service Desk).
2. This access is obtained by being a member of a group assigned to a Jira application. Default
groups are automatically set up for each application. Groups are used – as opposed to
granting individual user access – in order to make administration at scale easier.
3. Jira admins can set up multiple access groups and mark multiple groups as a default, if
desired.
4. When Jira administrators create a new user, they specify which Jira application(s) the user will
be using or just accept the default group for that application. The user will then automatically
be added to the default group(s) associated with the application(s).
5. Jira-administrators group is assigned to all applications, but it shouldn’t be the default.
6. You need a license for Jira Software and Jira Service Desk to see any features or functions that
are specific to that application. For example, a Jira Core user might be able to see a Jira
Software project (assuming that he has Browse Projects permission) but would not be able to
see any Jira Software specific features, like Agile boards, development tools, or release
information. These features can only be viewed by a user with Jira Software application
access.

68-<Jira Administration for Data Center and Server>

 Global Permissions
1. Control what users can do in the system as a whole, not in particular projects.
2. Each permission is granted to one or more groups. This is one of a few places where
only groups can be added, and not individual users or project roles.
3. There are only 6 global permissions
4. Jira System Administrators
5. Jira Administrators
6. Browse Users
7. Created Shared Objects
8. Manage Group Filter Subscriptions
9. and Bulk Change. Make sure you understand what each one does. We discussed filter
subscriptions and bulk operations earlier in the course.
10. Only Jira administrators can update global permissions

69-<Jira Administration for Data Center and Server>

 Project permissions are granted through a permission scheme that is associated with
one or more projects.
1. They control what users can do in particular projects.
2. There are many permissions ranging from creating issues to viewing the workflow. A
few permissions are application specific, like the ability to Manage Sprints in Jira
Software projects.
3. Each permission can be granted to a variety of entries – groups, roles, Reporter,
Assignee, Project Lead, User Picker or Group Picker custom fields, and others.
4. Although you can also add single users to project permissions, you should avoid doing
so, as that is less flexible and scalable.
5. The Browse Projects permissions is most important because no matter what other
permission a user may have (such as Transition Issues, Delete Issues, etc.), if they do
not have Browse Projects permission, they cannot even see the project at all or any of
its issues.
6. Like other project schemes, only Jira administrators can edit permission schemes.

70-<Jira Administration for Data Center and Server>

 If in doubt, try to use Project Roles.
1. Roles are a way to associate some people with some projects.
2. You can add either individual usernames or groups into project roles, but groups are
preferred whenever possible as a best practice.
3. You can use either groups or project roles in many places throughout Jira. For
example, notification and permission schemes, as well as workflow conditions.
4. Whenever you have a choice of group or role, project roles are preferred.
5. They are generally more efficient, flexible, sustainable than groups. However, there
will be some situations when a group makes more sense. Can you think of them?
6. Finally, roles allow permission management to be delegated to project
administrators.

71-<Jira Administration for Data Center and Server>

 This is a good time to talk about Project Administrators.
1. These are users with the Administer Projects permission. So a user may be a project
administrator in just one or two projects in Jira, but not all.
2. They can update project details, namely the project name, project description, project
lead and URL. And also versions and components
3. And manage membership in the roles within their projects. This is one of the most
compelling reasons to use project roles rather than groups in various schemes,
because
4. through use of roles, project administrators can effectively manage:
5. project permissions
6. notification recipients
7. issue-level security
8. and workflow permissions
9. Remember that only Jira administrators can modify groups and schemes. But by
creating roles and using them in schemes, Jira administrators delegate responsibility
to project administrators at the project level. This helps to relieve them of some of
their administrative burden, and it allows them to create fewer, more standardized,
schemes.

72-<Jira Administration for Data Center and Server>

 As an example, let’s say that – based on some business scenario on an exam question –
you must decide whether individual users, a group or a project role needs to be added to
a permission. What are some of the relevant questions to consider – that will help you
narrow down the answer? Here are a few of them.
1. Is it a global or project permission? If it’s a global permission, then only groups can
be added. Let’s assume we are asking about a project permission.
2. Do many users need to be added?
3. Do they change often?
4. Do they vary by project?
5. Should project administrators be able to make updates? If yes to all these questions,
then project roles are definitely the way to go because they allow project
administrators to manage their users on a per-project, as-needed basis without
having to involve the Jira administrator. In some case, however, groups are better. For
example, if many projects share a scheme and the number of users is small and never
changes.
6. Make sure the answer is the most robust option that will reduce, and not add, to the
administrative overhead.

73-<Jira Administration for Data Center and Server>

 The next objective is to identify and troubleshoot user settings, user profiles and
permissions. As mentioned earlier, many exam questions present either business
requirements – for which you must choose a recommended configuration – or an issue for
which you must find a root cause. In both cases, you must first know and understand all
the settings related to a particular content area, so you can figure out which one is
relevant.

74-<Jira Administration for Data Center and Server>

 With respect to security and permissions, we covered many of these in previous slides,
including:
1. application access
2. global permissions
3. project permissions and permission schemes
4. filter and dashboard sharing
5. groups
6. project roles
7. issue-level security
8. and workflow conditions. The last two will be covered in later modules.

75-<Jira Administration for Data Center and Server>

 Once you have the relevant settings in mind, you need to ask the relevant questions –
what and where.
1. What action is the user able or unable to perform?
2. Is it Create, Edit, or View something?
3. Attach or Comment
4. Transition or Log work
5. Or Bulk Change, just to name a few.
6. And where (at what level) is the problem occurring?
7. At a global level of the Jira application
8. Or at the project level?
9. Or perhaps board, filter or dashboard
10. Or just a single Issue
11. And is it an Issue operation
12. Or a workflow transition, etc.? This kind of breakdown will help you focus in on the
narrower list of settings that are involved in troubleshooting and fixing a permission
problem.

76-<Jira Administration for Data Center and Server>

 So as our example, let’s think through five common troubleshooting scenarios and see
which of our settings are relevant.
1. User can access one project in Jira, but not another.
2. The problem is at the project level, in the permission scheme, and specifically the
Browse Projects permission.

77-<Jira Administration for Data Center and Server>

 A user can see and execute one workflow action, but not another
1. The problem is at the level of a project workflow. The relevant setting is a Workflow
Condition, which may then lead us to troubleshooting Groups, Roles or permissions
such as Resolve Issues or Close Issues from the Permission Scheme.

78-<Jira Administration for Data Center and Server>

 The user can see one Issue in a project, but not another.
1. The problem is at the issue level. The relevant settings are Issue Security Scheme and
Security Levels, which may again lead to checking Groups, Roles, etc.

79-<Jira Administration for Data Center and Server>

 A user can see one software board but not another.
1. Can they see the project? If not, then check the Browse Projects permission at the
project level. Otherwise, check the board filter and with whom that filter is shared.

80-<Jira Administration for Data Center and Server>

 If the user cannot see any software boards,
1. then check Application Access to Jira Software and the groups listed there. Recall
that only a Jira Software user can see any product specific features, like Agile boards,
development tools, or release information. By knowing all the related settings, and
then asking the relevant What and Where questions, we can focus on the potential
root causes of a troubleshooting question. This same kind of analysis of asking
distinguishing questions will help you understand troubleshooting questions in other
sections, like notifications and workflow configurations.

81-<Jira Administration for Data Center and Server>

 Let’s look at the next objective. Given a scenario, recommend the appropriate
configuration of user and project permissions, roles and group membership.

82-<Jira Administration for Data Center and Server>

 Let’s begin with the considerations.
1. You need to know how and why groups and project roles are used – they are most
often used to control what users can or cannot do in a project – through permissions
and workflow conditions, and sometimes what they can see (through use of issue-
level security). So you definitely need to know all the project permissions we covered
earlier.
2. You also need to consider whether the permission scheme already is (or must be)
unique to the project or shared with other projects. As we have already discussed,
using project roles (and varying the membership in those roles for each project)
allows you to share permission schemes.
3. You’ll also be presented with scenarios where you need to judge whether to create
new groups or project roles, or to use existing ones. Remember that you should reuse
whenever possible and appropriate in order to reduce administrative overhead.

83-<Jira Administration for Data Center and Server>

 Hence, let’s recap the use of groups versus project roles, which is central to this objective.
The question of when to use groups and when to use project roles is one that you’ll
encounter frequently as a Jira administrator, so it’s important that you consider all of the
scenarios you’ve worked with, and how and why you’ve reached decisions around which
option to use.
1. Where can you use either groups or roles?
2. You can use either in permission schemes, notification schemes, in the security levels
of an issue security scheme, and in workflow conditions, for example. Filter and
dashboards can also be shared to certain groups or roles. Recall that roles are
generally preferred over groups because they allow more reuse and greater flexibility.
3. Where can you use only groups?
4. Application access, global permissions, group filter subscriptions.
5. And remember that you can also use groups (and individual users, of course) inside of
project roles. But you cannot use project roles inside of project roles.

84-<Jira Administration for Data Center and Server>

 And why are roles preferred over groups?
1. They are more efficient, flexible and sustainable than groups
2. Only Jira administrators can modify groups and schemes
3. Whereas project administrators can modify membership in project roles
4. Which essentially delegates provisioning of project access to the project administrators.
5. So you should aim to develop flexible permission schemes that can be shared across
many projects.

85-<Jira Administration for Data Center and Server>

 In this example, let’s see if groups or roles are better. Though these examples are brief
and general, you will receive more details in the exam question about the context and
business requirements to help you narrow down the appropriate configuration.
1. What is better groups or roles if many projects share a permission scheme and the
users vary by project?
2. The is the gold standard for project roles, because you can add the Role into the
required permission(s) and then add the right users into the right projects.
3. What if the exact same 5 people need the same permission in many projects?
4. Then a Group might be better. You can add the single group into the scheme instead
of having to add the same people over and over again into the role of every project.
5. If Project Administrations need to be able to control permissions for others
6. Then we’re back to the gold standard. Project Roles are better because Project
Administrators can manage roles but not groups.

86-<Jira Administration for Data Center and Server>

 Our next objective. Given a scenario, determine the impact of deleting/ deactivating a
user/group.

87-<Jira Administration for Data Center and Server>

 Users and groups sometimes need to be removed for different reasons.
1. You must know the reasons and the prerequisites for deactivating or deleting users
globally
2. Such as exceeding license limits
3. Or for compliance
4. or data security reasons
5. or simply because a person has left the company.
6. and you need to understand the impacts of those user references in either method.
7. For example, think of the ways in which filters can be impacted because the JQL used
to generate the filters will no longer be relevant if a deleted user is referenced.
8. Or what if you the user was referenced in some aspect of workflow configuration?
Then that workflow may no longer work as expected.
9. You should understand the differences between deleting and deactivating. Let’s look.

88-<Jira Administration for Data Center and Server>

 Deactivating users is common.
1. A deactivated account will prevent the account from being used.
2. Deactivated users cannot login
3. Or be counted towards your Jira application license limit.
4. They will not receive any Jira email notifications
5. They cannot be assigned or added as a watcher to issues
6. However, deactivating users will preserve that user's work activity and history.
7. They can be used in search queries
8. They will continue to appear on issues they have worked on with (Inactive) displayed
after their name.
9. Deactivating is preferred over deleting a user, especially if the user reported, commented on, or
has been assigned issues. Then you can’t delete them.

89-<Jira Administration for Data Center and Server>

 Deleting users is a bit trickier.
1. When you delete a user, it also deletes their filters and dashboards, even if they're
shared with other users, so this is one reason for deactivating rather than deleting.
2. Deleted users cannot be used in search queries
3. But historical data created by the deleted user is preserved and can be reused if
another user account is created using the same username.
4. You cannot delete a user from Jira if they have reported or been assigned to any
issues or commented on any issues.

90-<Jira Administration for Data Center and Server>

 As an example, let’s look at the difference between User1 who was deactivated and
User2 who was deleted.
1. Neither of the users can login
2. Neither counts toward the license limit
3. A deactivated user can be used in searches, but not a deleted user
4. Filters and Dashboards are not deleted for User1 but yes for User2
5. Neither deactivated nor deleted users can remain as Project or Component Leads.
They need to be replaced before deleting or deactivating them.
6. Deactivated users can remain as the Assignee or Reporter or Watchers of issues, but
deleted users cannot

91-<Jira Administration for Data Center and Server>

 The final concept in this section is to determine if and how issue-level security should be
configured in a project. So that, for example, Group1, can see some of the issues in a
project, but not all

92-<Jira Administration for Data Center and Server>

 and Group2 can see a different set of issues in that project

93-<Jira Administration for Data Center and Server>

 The first part is to determine if a use case warrants configuring Issue Level Security.
1. Issue-level security controls the visibility of individual issues within a project, so some
of the issues are visible to some of the users within a single project, and other issues
are visible to others, and perhaps there are also issues which are visible to both
groups, and some issues visible to anyone with Browse Projects permission.
2. One or more issue security levels are created within issue security schemes. The levels
control which users or group of users can view an issue in that level.
3. Issue Security is a permission in the project’s permission scheme. You need to have
this permission to be able to set Security Levels.
4. Security Levels can be set either by default or manually by users with that Set Issue
Security permission.

94-<Jira Administration for Data Center and Server>

 What configurations are needed to enable Issue Level Security within a project?
1. Issue Security Schemes do not come automatically preconfigured in a Jira instance.
Jira administrators must first create an Issue Security Scheme
2. and then one or more Security Levels within the scheme.
3. You can optionally set a default security level so that newly created issues
automatically inherit that level at the time of creation.
4. You then add various entries to security levels such as Assignee, Reporter, Groups,
Project Roles, or custom fields of type User Picker, for example.
5. When ready, you associate the Issue Security Scheme with the right project(s).
6. You grant the Set Issue Security permission to those who should be allowed to set (or
edit) the Security Level field.
7. And ensure that the Security Level field is on the right project screens.
8. Remember the golden rule. “Browse Projects” permission is always needed in order to
see issues in a project, regardless of Security Level settings and membership.

95-<Jira Administration for Data Center and Server>

 Assuming all those pieces have been configured correctly, what are the implications?
1. Secured issues become inaccessible (not visible) anywhere in Jira to a user who is not
listed in issue’s Security Level. This includes:
2. Backlog and Active Sprints
3. Service Desk queues
4. search results and saved filters
5. And reports and gadgets.
6. Also, notifications are not sent to a user not permitted to see it, even if the user is
listed in the notification scheme.
7. And secured issues are not linked in the issue links section and the issue keys are not
hyperlinked (in Description, Comment, etc.) when viewed by a user not in the issue’s
Security Level.
8. Another implication is that sub-tasks automatically inherit their parent’s Security
Level
9. The Security Level field is editable only to users with both Set Issue Security and Edit
Issues permissions, and they can only select a Security Level in which they
themselves are listed.
10. Finally, at issue creation time, if the Reporter does not have Set Issue Security
permission, then the default security level is set (if there is one), otherwise it is set to
“None”, which means the issue won’t be secured.

96-<Jira Administration for Data Center and Server>

 Let’s look at several typical use cases for configuring issue-level security:
1. Certain issues should only be seen by a certain static or dynamic set of users. This is
the most common use case. Let’s say that all HR representatives can see all issues in
the HR Project, except those where the issue type is Termination. Those issues should
be visible only to HR managers.
2. A static set of users means that you can put individual users, groups, or Project Roles
as entries into the security levels.
3. And dynamic means that you can put custom fields, like single or multi-user Picker
and Group Picker fields, as entries into security levels, which can then be edited
dynamically on the issue itself.
4. Another use case is that Reporters should only see their own issues. Here, you can
create a Reporter Security Level and add the Reporter entry (plus Jira administrators
or project administrators, as a best practice). With this use case, there is another way
to achieve it – by putting Reporter into the Browse Projects permission. Investigate
the pros and cons.
5. We can also use issue-level security for hiding (archiving) certain issues in a project so
they don’t clutter the project or Jira.

97-<Jira Administration for Data Center and Server>

 The fourth module is General Project Configuration.

98-<Jira Administration for Data Center and Server>

 It contains 5 objectives.

99-<Jira Administration for Data Center and Server>

 Describe the appropriate use of general project settings (key, category, etc.) These are the
first settings you’ll set up when you create a project in Jira.

100-<Jira Administration for Data Center and Server>

 Project details include Name, Key, URL, Project type, project category, avatar, Description,
Project Lead, and Default assignee

101-<Jira Administration for Data Center and Server>

 When creating a project, choose a key that will suit your long-term needs. While Jira will
work as expected for the most part while changing a project key, there are some
limitations and impacts.
1. The old project key can be used in JQL queries.
2. All attachments will be accessible after the project key change.
3. Issue links with the old key will work as expected, but link aliases will not be
updated. They will read as their previous name, but luckily all links will return the
correct issues.
4. You won't be able to create a new project with the old project key. You can however
change the renamed project back to the old project key.
5. Deleting the project allows reuse of the project key
6. No matter what, such changes should be scheduled during periods of low user
activity, because Jira will start a background re-index when you save your updated
project key. And this can have a performance impact.

102-<Jira Administration for Data Center and Server>

 Additional impacts include
1. Changes to the Project Lead or Default Assignee. This may impact the various places
they are used such as:
2. Component assignments
3. Permissions
4. Notifications
5. workflow conditions
6. And Security levels
7. Project category could be used in queries, so changing it might impact saved filters.
8. A project might need to move to a different type, but this is a major change, especially
if that project has been around for some time. You might find it easier to create a new
project instead and move issues into it.

103-<Jira Administration for Data Center and Server>

 Here’s our example. Your organization is frequently adding new DEV projects. As a result,
users must keep updating queries such as this one:
Project in (SPACE, ENG, DEV, MOB) and issueType = Bug.
They want to avoid making frequent updates to saved filters whenever new DEV projects
are created. What change can help them?

1. The solution is to add all DEV projects into a project category like Development. The
Category field searches for all projects within the category.
2. The JQL would be Category = DEV AND issueType = Bug. And those saved filters will
not have to be updated each time a new DEV project is created, so long as the new
project is added to the Development category.

104-<Jira Administration for Data Center and Server>

 Our next objective is to determine whether to modify an existing project, and/or create a
new project to meet business requirements.

105-<Jira Administration for Data Center and Server>

 New business requirements emerge, and others change. As a Jira Administrator, you
often need to make decisions about whether to modify existing projects to meet those
requirements or to create entirely new projects. To make that determination, you must
first consider all the various configurations that make up a project. This includes:
1. Schemes related to the entire project like Notification Scheme and Permissions
Scheme
2. Schemes based on the Issue Types in a project, like the Workflow Scheme and Field
Configuration Scheme
3. Optionally an Issue Security Scheme, if it is needed
4. Versions
5. Components
6. Project Details, as discussed in the previous objective
7. And memberships in Project Roles, etc.

106-<Jira Administration for Data Center and Server>

 Here are a few sample reasons why you may need to create new projects to
accommodate new or changing business requirements. Keep in mind, that this is not a
definitive list. An exam question will have more context for you to decide.
1. One reason is a need for separate permissions which cannot be accommodated with
use of Project Roles.
2. Another may be the need for issue-level security.
3. Different components may or may not require separate projects, depending on
whether the lists can be combined, whereas different component leads for the same
component definitely will require a new project.
4. A different release cycle, hence different versions, would usually require a separate
project.
5. Bottom line, you might assume that modifying the project is better and then look for
definitive reasons why it must be separate.

107-<Jira Administration for Data Center and Server>

 As an example, let’s look at 2 scenarios where a team is changing their processes. You
must decide if you can change their current project or create a new one to meet their new
requirements.
1. In the first scenario, 2 issue types currently share a single workflow. Those workflows
must now be unique.
2. For this scenario, you can create or update the different workflow(s) and associate to
each issue type as needed in the existing project.
3. In the second scenario, the team is splitting into two and will work on different
components with auto-assignment for each.
4. We need separate projects if the components are different for the two teams. It is
also likely that they will no longer share the same permission or notification schemes
or at least have different members in project roles. Hence, we need to create a new
project and set up the schemes and project role memberships accordingly. And we
may need to move issues, as well.

108-<Jira Administration for Data Center and Server>

 In our next objective you must determine whether to use an existing project template,
and/or modify project schemes to meet business requirements.

109-<Jira Administration for Data Center and Server>

 First, you must be familiar with the three project types. Depending on which JIRA
applications you have installed, you may have more than one project type available. Each
project type has a specific set of features. Assuming they have Browse Projects
permission, then all users in the JIRA instance will be able to see all projects. However,
the features they see and the actions they can perform are determined by their
application access and the project specific permissions.
1. Business project types offer core Jira functionality.
2. Software project types offer Boards, Release Hub, and Agile Reports in addition to
that core functionality
3. Service Desk project types have Queues, SLAs, Knowledge Base integration, Customer
Portal, and Request Types among other features

110-<Jira Administration for Data Center and Server>

 When you create a new project from a template, that project is created with its schemes
as follows:
1. The permission scheme is a default scheme shared with other projects of its type.
2. The notification scheme is shared with all other projects
3. and so is the default field configuration
4. And the default priority scheme
5. Therefore, all four of these are shared
6. However, the issue type scheme
7. the issue type screen scheme
8. And the workflow scheme
9. Are unique to a project created from a template. For each template, there are some
differences in these schemes such as different default issue types and different
workflows. You should be familiar with the main characteristics of these
automatically created schemes.
10. And as far as the issue security scheme
11. It is not created by default. If needed, it must be created, configured, and associated
by a Jira administrator at a later time.
12. But of course, no matter what template is chosen, you can modify the default
configurations to meet the exact needs of the business. The test taker will be
expected to evaluate a scenario and know if and where the change could be made.

111-<Jira Administration for Data Center and Server>

 Projects can also be created with a shared configuration.
1. This means they are created with the same scheme configurations as another
existing project.
2. In this way, two or more projects can share all of their schemes.
3. Versions, Components, and Project Roles are not shared, however
4. Know also that you do not have to keep all of the schemes shared with one or more
projects. You can pick and choose. That’s the power of Jira configurability.
5. The most important thing to remember is that changes to a shared scheme may
impact multiple projects. Jira administrators must understand and assess the impact
of their changes across the projects.

112-<Jira Administration for Data Center and Server>

 Hence know the pros and cons of shared schemes versus unique (or custom) schemes.
1. On the Pro side, sharing Schemes reduces Administrative Overhead. They are easier to
manage, changes will apply to all projects using the scheme, you can enforce
consistency & standardization, and fewer schemes means less impact on
performance.
2. On the Con side of Shared schemes, there is limited flexibility. Multiple stakeholders
usually need to be consulted for every change. Otherwise, there may be errors and
unwanted side effects in the other projects.
3. On the Pro side of unique/custom schemes, you have the fact that you can satisfy very
specific business requirements. And of course, modifying a scheme doesn’t impact
other projects.
4. But the cons include administrative overhead and impact on performance. And you
need to do careful management when you have so many schemes.

113-<Jira Administration for Data Center and Server>

 Let’s say that the HR project was originally created from a template. The team now has
new business requirements – to begin tracking new hires, which requires a unique
workflow. Should you create a new project or modify the existing one? What changes
would be required to accommodate this?
1. The answer is that you can probably do this by making configuration changes to the
existing project as follows:
2. Create a new issue type
3. Add the new issue type into the Issue Type Scheme
4. Create a new workflow
5. and Associate the new workflow to the new issue type in the project’s workflow
scheme.

114-<Jira Administration for Data Center and Server>

 Describe the appropriate use of components and versions. Both can be used to group
issues together for ease of management, but let’s distinguish what they do and how they
are used.
Jira Core does not use Versions and/or Components.

115-<Jira Administration for Data Center and Server>

 Let’s start with Versions.
1. The Releases page which is accessible from the project sidebar shows the list of
versions in the project.
2. Those version values show in the Affects Version(s) and Fix Version(s) fields, which are
multi-value system fields.
3. The actions you can perform on Versions is to Release, Archive, Merge, Edit, and
Delete.
4. Archived versions are visible on an issue and can be searched on. But you can no
longer select an archived release value on an issue.
5. You can also add custom fields of type Version Picker
6. The Release Hub, which is is only available in Software projects, shows the progress
of a version and information from connected development tools, if any.

116-<Jira Administration for Data Center and Server>

 Components
1. Is a multi-value system field
2. It is used to group or sub-categorize data in a project, often for reporting purposes
3. More importantly, it is also used for automatic assignment to be able to triage issues
based on component. Namely, if you select a particular component on an issue, it can
be automatically assigned to the designated component lead.
4. And while labels and Custom fields can also be used for categorizing issues, they do
not offer this valuable feature of automatic assignment.
5. Note that you can add a Component Lead and choose not to make them the default
assignee. The default assignee for a Component can be the Component Lead, Project
Lead, Project Default, or Unassigned. Let’s look at an example of automatic
assignment.

117-<Jira Administration for Data Center and Server>

 If an issue’s component is set to Database when it’s created, to whom will the issue be
assigned? In this example, the project has 5 components, each with a component lead
and a default assignee.
1. If an issue’s component is set to Database when it’s created
2. Then the issue will automatically be assigned to the component lead
3. Which is Emma Paris.

118-<Jira Administration for Data Center and Server>

 And what if another component is selected during issue creation?
1. For the login component
2. The lead is Ryan Lee
3. But the default assignee is set to project default. And that could be either the project
lead or unassigned. Unfortunately, we do not see this from here but rather on the
Project Details page which we learned about in objective 4.1. So we would need to
see that information before answering the question.
4. And what if an issue is created with multiple components, and those components
have Component Leads set as default assignees and they are not the same person?
To whom is the issue assigned?
5. The issue will be assigned to the default assignee of the component that is first
alphabetically.

119-<Jira Administration for Data Center and Server>

 Here is our final objective in this 4th module. Determine which project activities should be
delegated to the project administrators. Basically what actions can be done by a project
administrator versus actions that can only be performed by a Jira administrator.

120-<Jira Administration for Data Center and Server>

 Recall from objective 3.1 that a project administrator can:
1. Update project details, versions, components
2. And Manage role membership.
3. They can also perform limited other actions
4. when Extended Project Administration is enabled in the project’s permission scheme
5. which is exclusive to Jira Server.

121-<Jira Administration for Data Center and Server>

 Extended Project Administration allows project administrators limited ability to:
1. Edit workflows
2. but only if it is used only by that project and it isn’t a default Jira workflow.
3. They can add a status, but it must already exist in Jira. They can’t create, remove or
delete statuses
4. They can also create, add, edit or delete transitions
5. but not their configurations – conditions, validators, post-functions, or properties
6. Project administrators can also edit fields and screens on a limited basis.
7. The screen must not be a default system screen or used as a transition screen in
workflows.
8. And the screen must not be shared with any other projects
9. The project admin can add, remove and rearrange system fields and existing custom
fields. But they cannot create custom fields. This information will be important for you
to know when deciding if the action can be completed by a project administrator or a
Jira administrator.

122-<Jira Administration for Data Center and Server>

 Your Jira has hundreds of projects using unique permission schemes. To ease your load,
you want to delegate management of permission schemes and group memberships to
various project administrators. Is this a good idea?
1. Actually, it is not possible. You must be a Jira administrator to modify schemes and
groups. However, if you start using more Project Roles, then you can delegate
management of Project Role memberships to project administrators. This effectively
allows them to modify permissions.

123-<Jira Administration for Data Center and Server>

 Our next module is Authentication and Security. We want to prevent the wrong people
from accessing Jira or any of its data.

124-<Jira Administration for Data Center and Server>

 This module has 3 objectives.

125-<Jira Administration for Data Center and Server>

 Our next objective is to evaluate the appropriate method of authentication and sign-up.

126-<Jira Administration for Data Center and Server>

 Here, you need to understand the Mode setting.
1. This is a setting in Jira’s General Configuration page.
2. Jira can operate in either Private or Public Mode
3. Private means that only administrators can create new users.
4. Public mode means any user can sign themselves up for an account and post issues.
5. Public mode is the same as saying that your Jira is a public instance or that it allows
public signup. Let’s look at each mode closer.

127-<Jira Administration for Data Center and Server>

 In Private Mode
1. Administrators create users
2. This could be Jira administrators, if the Jira Internal Directory is used
3. Or LDAP administrators, if an external user repository is used to bring in users
4. In either case, you have tight access control
5. And therefore you can better monitor the number of licenses being used

128-<Jira Administration for Data Center and Server>

 In Public Mode
1. Users create their own accounts, so administrators don’t need to be involved.
2. Of course, this means a potential increase in the number of licenses needed
3. New users are automatically added to the default application group, so you also
need to be aware of what they’ll be able to do.
4. Even if you enable signup, it is still necessary for users to have the appropriate project
permissions before they can see or create issues.
5. If you put a self-signup system onto the internet, you may want to enable CAPTCHA.
6. So which mode is ultimately better for an organization? It depends on the needs of
the organization and striking a balance between security and flexibility.

129-<Jira Administration for Data Center and Server>

 You notice weird user accounts in Jira. What should you check?
1. Well, the Mode setting as we have just learned. It is probably set to Public.
2. But perhaps some of these weird accounts are coming from bots. Is CAPTCHA
enabled?
3. Perhaps you should also enable or update the Password Policy. That’s our next
objective.

130-<Jira Administration for Data Center and Server>

 Determine the appropriate password policy to be applied.

131-<Jira Administration for Data Center and Server>

 Password Policy
1. is disabled by default
2. and it is only useful when Jira users are able to change their own passwords
3. If Jira is connected to an external user management system, this policy should not be
used since passwords are maintained externally from Jira.
4. So you have four options
5. Disabled – The equivalent of having no password policy
6. Basic – Requires passwords to be at least 8 characters long and use at least 2
character types. Rejects passwords that are very similar to the previous password or
the user's public information.
7. Secure – Requires passwords to be at least 10 characters long and use at least 3
character types including at least 1 special character. Rejects passwords that are
even slightly similar to the previous password or the user's public information.
8. Custom – Lets you use your own settings, such as a password length, character
variety and similarity checks.

132-<Jira Administration for Data Center and Server>

 So let’s say you enabled a stricter password policy. What effect will this have?
1. Will users be sent an email to reset their password?
2. No, they won’t.
3. Will users with weak passwords be forced to change them on next login?
4. No, they won’t.
5. Will users be forced to pass CAPTCHA tests until they have set a strong password?
6. No, they won’t.
7. Will new users and those who change their passwords have the rules enforced?
8. Yes

133-<Jira Administration for Data Center and Server>

 In the final objective, let’s assess whether or not Jira is appropriately secured. We will
learn about a few more security-related topics.

134-<Jira Administration for Data Center and Server>

 Public sharing
1. This is an On/Off setting and it is also found on the General Configuration page in Jira
system administration
2. On means “Allow users to share dashboards and filters with the public”
3. Public means all users including those that are not logged in
4. Users can view publicly shared objects by searching for those “Shared With Anyone.”
5. Disabling this setting will not effect those already shared with the public.
6. You will need to check whether there are already objects shared with public and
change these yourself.
7. Dashboard and filter names could also contain sensitive information. For example,
“Tasks for next merger”, etc. And you have no control over the audience, nor search
engines and bots. So consider if you want to enable this or not.

135-<Jira Administration for Data Center and Server>

 Group Anyone
1. Is a choice of Group, not the actual name of a group.
2. It is available when setting global and project permissions in Jira.
3. When added, it means that any person who can access your Jira instance can then
perform the permitted action without being logged in.

136-<Jira Administration for Data Center and Server>

 Anonymous Access
1. refers to granting global or project permission to Group “Anyone” as just explained.
2. When Group ”Anyone” is added to permissions in one or more projects, it means you
have enabled Anonymous Access.
3. Generally, you would want to limit this to just the Browse Projects permission
4. Because Anonymous Users are indistinguishable if you provide them Create Issues or
Edit Issues permissions.
5. Anonymous users can also see the names of publicly shared filters and dashboards if
Public Sharing is turned ON.
6. Anonymous users can use only Jira Core features. Neither Jira Software nor Jira
Service Desk features can be granted to anonymous users.

137-<Jira Administration for Data Center and Server>

 There are two HTML related settings
1. in Jira’s General Configuration page
2. Enable HTML in project description
3. Enable HTML in custom field descriptions and list item values
4. Both of these should be disabled due to security reasons because the settings also
allow potentially malicious JavaScript to be executed in the background.

138-<Jira Administration for Data Center and Server>

 There are two other settings
1. in Jira’s General Configuration page
2. User email visibility
3. indicates who can view user email on the user profile page.
4. It can be set to Public, Hidden, Masked, or Show to logged in users only
5. This is a common measure you can take against spamming.
6. Especially when you have anonymous access allowed, or when you are running your
instance in public signup mode. It can be important to protect information by masking
them or showing them only to logged-in users or hiding email addresses altogether.
7. And Comment visibility
8. To enable comment and worklog visibility
9. based on groups and project roles
10. Or just project roles

139-<Jira Administration for Data Center and Server>

 So when assessing whether Jira is properly secured, consider all of what we have just
learned in these 3 objectives.
1. Private vs. public mode
2. Password policy and CAPTCHA
3. Public sharing
4. Anonymous access
5. HTML in projects or custom fields
6. And comment and email visibility settings
7. There is also Jira’s Whitelisting feature, which allows you to control the outgoing
connections that Jira is allowed to establish. It is automatically enabled and should
not be disabled unless you have other measures to prohibit connections to untrusted
services. All URLs of linked applications and Atlassian itself are automatically
whitelisted.
8. Jira’s Audit log is helpful to see what, when and by whom something was changed.
9. Finally, you need to know when you can make tradeoffs. Business requirements may
conflict with security best practices. Consulting organizational policies is important.
You need to explore viable alternatives and know when to push back.

140-<Jira Administration for Data Center and Server>

 You want to prevent bots from getting access to your public Jira instance and protect
your users’ contact information. An example is to ensure that only humans are able to
sign-up new accounts. In addition to that, it is important to protect contact information
of all users from bots and sometimes even from other users. What can you do?

1. CAPTCHA on signup should always be enabled on public instances.

2. You should set Maximum Authentication Attempts Allowed.
3. Also set User email visibility.

141-<Jira Administration for Data Center and Server>

 Module 6 is issue types, fields and screens.

142-<Jira Administration for Data Center and Server>

 This module has 5 objectives.

143-<Jira Administration for Data Center and Server>

 Given a scenario, identify and implement appropriate changes to built-in fields including
statuses, resolutions, priorities, translations, and issue types. As a Jira administrator, you
need to be able to manage fields in Jira, both system and custom fields. This objective
deals with 3 of the built-in system fields: Status, Resolution, and Priority. The available
values in these fields are modifiable by Jira administrators, but with due caution.

144-<Jira Administration for Data Center and Server>

 Statuses are first.
1. They represent the position of the issue within a workflow.
2. They are global to Jira which means they are available to be used throughout a Jira
instance, but of course not all statuses are used in every project.
3. A default set of statuses ships with Jira like Open, In Progress, Closed, etc.
4. and some statuses are created when projects are created from templates. For
example, the Rejected status – if it does not already exist – is added to Jira when a
project is created from the Process Management project template.

145-<Jira Administration for Data Center and Server>

 Statuses can be added through the following locations:
1. the Statuses page in Jira administration where you see the name and category of the
status, as well as all the workflows where the status is used
2. You can also add a new status while editing a workflow
3. And finally, through board configuration
4. But to add a status to a board the project must be using the Simplified Workflow.
5. And you need to be either a Jira administrator OR a project administrator and a board
administrator. If you are only the board administrator (and not a Jira administrator or
the project administrator) you can configure the board, but you can only add columns
to the board but not statuses to the simplified workflow.
6. As a best practice, Jira administrators should start simple and add statuses only
when you really need them. Don’t create a lot of statuses. Create a status whenever
there's a handoff from one person to another or a piece of work is going to be in that
same status for a long time.

146-<Jira Administration for Data Center and Server>

 With respect to modifying statuses:
1. Renaming a Status via a workflow affects all occurrences of the status
2. in all workflows
3. on boards
4. and in JQL queries of saved filters
5. As well as reports
6. And dashboard gadgets
7. And finally, deleting a status
8. is only possible if there are no associated workflows using that status.
9. However, there may be JQL queries which referenced that status. Once it is deleted,
they will return an error that the value of the status does not exist. So check before
removing a status that it’s not being used.

147-<Jira Administration for Data Center and Server>

 Resolutions
1. explain why an issue transitions from an open status to a closed one.
2. Like statuses, resolutions are also global in Jira, and not per project.
3. And Jira ships with a default set of resolutions like Done, Won’t Do, Duplicate, etc.
4. Jira administrators can add, rename, or delete them through the resolutions screen in
Jira administration.
5. Deleting a resolution
6. Requires changing it to something else
7. And, like status deletions, it may affect JQL queries which referenced it
8. It’s important to maintain a limited list of resolutions that can be used across
projects. Too many will confuse the end user and generate bad data. You should also
make sure that they are written in easy to understand, plain language.
9. With respect to system maintenance, if a legacy Jira instance has been proliferated
with too many similar or unused resolution choices, doing a cleanup is a good way to
proceed. You can consolidate the ones which are similar and remove those which are
rarely used.

148-<Jira Administration for Data Center and Server>

 You must also know how and why resolutions are set.
1. The Resolution field appears on native Resolve screens and you can also place them on
custom transition screens used by a workflow.
2. If the Resolution field appears on a screen, it is required. So you wouldn’t want to place it on a
Create screen, for example, as users will not know the value at the point of creation.
3. It is crucial to remember that Resolutions can be set either
4. manually by the user on a screen – usually presented during the last step of a workflow OR
5. Resolutions can be set automatically via a workflow post function on one or more transitions.
And in fact, multiple ways can be set during a single workflow. You can have a couple
transitions that set the Resolution automatically (such as Duplicate and Works As Designed)
and one that prompts the user to select a value while closing issues in other situations.
6. If you are prompting the user to set the Resolution value, then the entire list of Resolutions
will be shown by default.
7. However, there is a way to refine the list of Resolutions presented to the user by adding
transition properties to limit the selection of resolution values via the workflow. These are:
8. jira.field.resolution.exclude
9. jira.field.resolution.include

149-<Jira Administration for Data Center and Server>

 Finally, you need to know why we set Resolutions and how they act in the system.
1. Resolution is independent of Status. The presence or absence of a Resolution value is
how Jira determines whether an issue is resolved or unresolved.
2. Regardless of actual status name, if a Resolution exists, then Jira considers the issue
resolved and sets the Resolved Date.
3. And an issue without a resolution is considered Unresolved, regardless of Status, and
there is no Resolved Date.
4. You should ensure that all issues get a Resolution value at some point in the process
flow, either manually or automatically. When an issue moves from an open state to a
closed state.
5. Likewise, resolution needs to be removed when an issue gets reopened, if the
workflow allows reopening. Resolution can be cleared only programmatically. The
user cannot clear the Resolution value on a screen.
6. The Resolution value is used in various reports and gadgets, for example the Created
versus Resolved Report. In other places, there might be a checkbox that says, “show
Resolved issues”. When enabled, issues with a Resolution will be included with open
issues, namely those which do not have a Resolution.
7. Bottom line, a resolution should always be added in the final state of a workflow and
cleared if an issue is reopened.

150-<Jira Administration for Data Center and Server>

 1. An issue's priority defines its importance in relation to other issues. This helps users to know
what to work on next.
2. Jira applications come with a set of default priorities.
3. The lists of priorities is defined globally in priority schemes. Jira administrators can create
new priority schemes and associate them with projects so different projects can have
different priorities.
4. Jira administrators can Add, rename, delete through the Priorities page in Jira administration.
5. They can also re-order priorities
6. change the priority’s icon and color
7. and set the default priority.
8. And as with resolutions, deleting a Priority value
9. requires choosing another value
10. but once again, remember that it might be referenced in JQL queries

151-<Jira Administration for Data Center and Server>

 Some fields come with a translate option so you can present the values in the user’s
chosen language.
1. You can specify a translated name and description for all values of the following
issue constants:
2. the issue type field
3. the status field
4. the resolution field
5. the priority field
6. This allows you to specify a translation set for each available language — providing
each user with a more complete translation in their own chosen language. The
translated field names and descriptions appear throughout Jira, in reports, gadgets
and all issue views.

152-<Jira Administration for Data Center and Server>

 Let’s look at an example. Let’s say that your Jira has been around a long time and has too
many Resolutions. You want to alleviate the problem and also avoid making users
choose Resolution values from the entire long list . What can you do?
1. Well for one, you should probably cleanup and consolidate the Resolution values. This
will involve choosing a new value as an old value is being removed. Also, you should
probably warn users about the potential impacts (to JQL queries, reports, gadgets).
2. Secondly, if possible, you might want to update your workflows – or at least the most
commonly used ones – to set the Resolution value automatically through a post
function versus prompting the user on a transition screen.
3. And finally, if you must prompt the user, you can add transition properties to display
only a few select resolution values.

153-<Jira Administration for Data Center and Server>

 Identify the appropriate issue type configurations to satisfy business requirements.

154-<Jira Administration for Data Center and Server>

 First, let’s define issue types
1. They represent the type of issue in Jira.
2. The list of issue types is defined globally but issue type schemes determine which
issue types are used by which projects.
3. A default set ships with Jira
4. And some are created from project templates. For example, Jira Service Desk
templates introduce issue types like IT Help or Fault.
5. There are Standard Issue Types
6. And Sub-task Issue Types. Remember we learned earlier that to use Sub-tasks in a
project, they must be enabled in the Jira system.
7. And like we have seen with the other system fields, you can add, rename, delete issue
types but that will affect the places they appear in Jira so know the impacts. Deleting
issue types includes issue migration. And renaming an Issue Type affects all
occurrences of the issue type in the entire system
8. And finally, issue types are not standalone. They are used as part of an Issue Type
Scheme which is associated with one or more projects.

155-<Jira Administration for Data Center and Server>

 Issue Types are quite versatile because you can map different behavior in Jira to different
issue types. Namely:
1. Different issue types are mapped to different workflows through the workflow
scheme.
2. Different issue types are also mapped to different field configurations through the
field configuration scheme.
3. And different issue types are mapped to different screen schemes through the issue
type screen scheme.
4. Then those schemes are associated with one or more projects.
5. Of course, you don’t always need to have different workflows, field configurations, or
screen schemes for different issue types. You can map all issue types to the same
single workflow, single field configuration and single screen scheme. You need to
distinguish if the business requirements warrant it by carefully analyzing a scenario
to see if they are needed or not.

156-<Jira Administration for Data Center and Server>

 When configuring a project, you must decide how to categorize issues and consider
whether issue types or other fields should be used for that categorization.
1. Since issue types are so important in the system, you don't want to create them
indiscriminately. A good reason is generally the need for having different workflows,
fields, or screens in a particular project.
2. You’ll need to know why you would create a new issue type instead of using
additional fields, such as components, versions, or other custom fields.
3. Sometimes the choice may even be adding an issue type versus creating a new
project. In the exam you’ll have questions that ask you for the best course of action
given a scenario. Can the requirement be resolved by creating a new issue type, or is
there something else that means we can avoid that additional overhead?
4. Again, it’s very much about avoiding clutter in Jira and reducing the administrative
overhead. So if there’s another solution that doesn’t involve creating a new issue type
you should use it, if it is efficient, practical, and achieves the goal

157-<Jira Administration for Data Center and Server>

 Let’s say a manager asked you to replace the Request issue type in his project with
Internal Request and External Request instead. What are the considerations in deciding
how to implement this?
Just asking some basic questions will help you decide if an issue type is needed or if you
can and should use a different way to distinguish between them.
1. Do internal and external Requests have
2. different workflows
3. different required or hidden fields,
4. or different screens when creating, editing or viewing issues? If the answer is yes to
any of these 3 questions, then yes, you’ll need separate issue types.
5. Also, if the manager needs to report on them separately; e.g. have a Two-dimensional
Filter Statistics gadget that shows Status by Internal issue type and Status by
External issue type, then this might also warrant adding the additional issue type.

158-<Jira Administration for Data Center and Server>

 That leads us to our third objective. Given a scenario, determine the effects of modifying
and restructuring active issue types and schemes.

159-<Jira Administration for Data Center and Server>

 As a Jira administrator, you need to know the impacts of adding new issue types into
active issue type schemes.
1. Here you need to consider all the configurations that are associated with Issue Types.
2. Does the new issue type need a separate workflow? If you add issue types into
active Issue type schemes, you might also need to set up new workflows and then
map them to Issue Types using the Workflow Scheme.
3. Does it need different required fields? You might need to consider the field
requirements for the issue type you’ve introduced and map those to the Issue Type.
For example, required fields or field descriptions or showing/hiding various fields for
that issue type.
4. Or perhaps the new issue type needs different screens or positioning of fields on the
screens of your newly added issue type. You’ll need to make sure that all the relevant
screen schemes and Issue Type screen schemes are in place for your newly added
Issue Type.
5. Do you need to set or modify the field contexts for any custom fields for that new
issue type? Remember that field contexts may be mapped to projects and/or issue
types.

160-<Jira Administration for Data Center and Server>

 There are also considerations for removing an issue type from an active issue type
scheme. Or else deleting an issue type entirely.
1. Before removing an issue type, you should bulk edit all issues of that type to another
existing issue type. You can then delete the original issue type without impacting
existing work.
2. Atlassian recommends not deleting any default issue types - you won't be able to get
them back if you change your mind later.
3. In fact, deleting an issue type should not be taken lightly. You should be completely
sure that you don’t need it.
4. And be sure you understand the impact to filters which reference an issue type that
was removed or renamed. Those filters may error or may not return the expected
results.

161-<Jira Administration for Data Center and Server>

 Understand the effect of moving issues across projects and/or issue types.
1. To change the issue type of an issue, you use the Move operation
2. Either within a single project or across projects.
3. And you can do this either for a single issue or in bulk. But you need to predict the
effects of doing an issue type move.
4. First, you need the correct project permissions in the projects, the Move Issues and
Create Issues permission. If a user cannot move issues, then check their project
permissions.
5. Second, if your issue is a custom issue type that does not exist in your target project,
you must select a new issue type to move to, or prior to moving, add that issue type
to the new project.
6. You may possibly also need to map the status during the move if the target issue
type uses a different workflow with different statuses
7. You may possibly also need to set values for required fields for the target issue type.
8. Issue types can be updated directly if the Issue Type field is present on the edit screen and both
types are configured identically, e.g. the entire configuration schemes are being shared
between the issue types.

162-<Jira Administration for Data Center and Server>

 For our example, let’s go back to Ahmed, the manager who asked you to replace the
Request issue type in his project with Internal Request and External Request instead.
Because the issue types need different workflows and different screens, you decided that
you will accommodate his request. What steps must you take to accomplish this
change?
1. First, you create the two new issue types, assuming they don’t already exist.
2. Next, you add the issue types to the project’s issue type scheme. But this assumes
that the scheme is unique and you are not impacting other projects. If it is a shared
scheme, you may need to create a new unique scheme, associate that with Ahmed’s
project, and then add the two issue types there.
3. Then you will do bulk move operations to move the right issues into the right new
issue type based on some criteria.
4. Finally, you will remove the Request issue type from the issue type scheme.
5. Of course, you can consider renaming the issue type, which saves you from creating
two new ones. But this may or may not be appropriate. It largely depends on whether
other projects are also using it or how that may impact various places in Jira, such as
saved JQL queries.

163-<Jira Administration for Data Center and Server>

 Determine the correct configuration of a field, considering field context, field
configuration (scheme) and screens (schemes). This exam topic is all about the
configuration of fields, and especially custom fields.

164-<Jira Administration for Data Center and Server>

 First, you should be familiar enough with system fields in order to be able to distinguish
them from custom fields.
System fields include, but are not limited to:
1. Issue Key, Project
2. Summary, Description
3. Reporter, Assignee,
4. Status, Resolution
5. Priority, Issue Type
6. Original Estimate, Remaining Estimate
7. Security Level and many more
8. The Summary field is the only field that is always required

165-<Jira Administration for Data Center and Server>

 System fields are often insufficient to meet business requirements, so custom fields
1. are often added to Jira to capture additional data, especially for reporting purposes.
2. You should be aware of the various field types available for custom fields including:
3. Text Field (multi-line), Text Field (single line) and Number Field
4. Date Picker and Date Time Picker
5. Radio Buttons and Checkboxes
6. Labels, Various Select Lists, and many more field types
7. Certain fields (like radio buttons, checkboxes, and select lists) allow you to set
options and defaults through the field context.

166-<Jira Administration for Data Center and Server>

 The custom field context is a complex concept in Jira. It is sometimes referred to as
custom field configuration context or as field scope.
1. By default, custom fields have a Global context which means that the field applies to
(or can be made available) in any project and issue type.
2. But more limited contexts can be configured (for example, for just one project or two).
And you can create multiple contexts for individual projects or issue types. This way,
custom fields can be limited in scope to show only in certain projects or issue types, if
desired.
3. Certain fields (like radio buttons, checkboxes, and select lists) allow you to set
options and/or default values. So the custom field context for a custom field specifies
4. the default value and options
5. and the projects and issue types to which these default values and options apply. You
can use a custom field context to set different options and/or different defaults for
different projects.
6. But there is one tricky fact. You cannot set multiple contexts for different issue types
in the same project.

167-<Jira Administration for Data Center and Server>

 A field configuration is a set of definitions for all fields.
1. It lists all the system and custom fields that are available in your Jira instance,
whether or not they are actually being used by a particular project. And for each field,
2. The field configuration specifies how that field appears and behaves, including:
3. the description that appears under the field when an issue is created or edited
4. whether the field is hidden or visible
5. whether the field is required or optional
6. Which renderer to use – wiki style or default text – for text fields
7. By default, when a project is created all the issue types for that project are mapped
to the Default Field Configuration. It shows all the fields configured in Jira, their
properties and where they are used.

168-<Jira Administration for Data Center and Server>

 A field configuration scheme
1. associates (or "maps") field configurations with issue types. You apply a field
configuration scheme to a project so you can define different field configurations for
each issue type that is available in a given project.
2. This allows you to specify different behaviors for a field, for each type of issue in a
given project.
3. As an example, we have the DEV Field Configuration Scheme. The Bug Field
Configuration is used for Bugs where the Due Date field is hidden and the Fix Version
field is required. Whereas the Task Field Configuration is used for Tasks where Due
Date is shown but Fix Version is hidden. That scheme is then associated with one or
more projects.

169-<Jira Administration for Data Center and Server>

 Let’s move on to another complex Jira administration topic – screens.
1. Screens contain fields. They are used to input data during issue operations, namely:
2. When creating issues, the Create Screen appears
3. The Edit Screen appears when a user edits an issue
4. The View Screen appears when a user views an issue. Remember that when viewing
an issue, you will only see fields when they have a value. If a custom field is empty, it
will not be visible on the screen in View mode.
5. Transition Screens are used when information is needed as an issue moves through a
transition in workflow. To make a transition screen available to users you associate it
with a workflow transition. For example, when an issue is resolved, we can indicate
how the issue was resolved via the Resolution Field.
6. Jira ships with some default screens used by various project templates and Jira
administrators can add more.
7. They can also group fields into various tabs.

170-<Jira Administration for Data Center and Server>

 Screen Schemes
1. associate screens with issue operations. This can be three different screens or a
single screen or two.
2. For example, the Bug Screen Scheme consists of 3 screens mapped to the 3
operations.
3. In the Task Screen Scheme, all 3 issue operations are mapped to just the one Task
Screen.

171-<Jira Administration for Data Center and Server>

 And finally we have the Issue Type Screen Scheme.
1. It associates screen schemes with issue types. So you can specify different screens for
particular operations, for each issue type.
2. Here, Bugs are associated with the Bug Screen Scheme, Tasks with the Task Screen
Scheme, through an Issue Type Screen Scheme that is then associated with one or
more projects.
3. What happens if an Issue Type Screen Scheme contains associations with issue types
that are not specified in a project’s issue type scheme? Then the mapping is ignored.
The same is true of Field Configuration Schemes and Workflows Schemes.

172-<Jira Administration for Data Center and Server>

 There is also a “Configure Fields” user setting that you should be aware of.
1. The setting allows individual users to control what fields they see on the screens. This
setting is available
2. When creating issues
3. And when editing issues. And which fields they see on each of those screens can be
different.
4. This allows each user to control what fields they see on a screen without impacting
what the rest of the team sees on the same screen.
5. However, required fields will always remain visible

173-<Jira Administration for Data Center and Server>

 One final thing to consider is permissions. Of course, by default there are no field
permissions. But Jira administrators should be aware that certain permissions can hide
certain system fields. Normally, you only need Edit Issues permission to be able to
update fields on the screen used for the Edit operation. But some of these system fields
are special.

174-<Jira Administration for Data Center and Server>

 To see and set the Due Date field, you need the Schedule Issues permission.

175-<Jira Administration for Data Center and Server>

 To set the Fix Version/s, you need Resolve Issues permission.

176-<Jira Administration for Data Center and Server>

 For the Security Level field – if/when an Issue Security Scheme has been applied to the
project – you need Set Issue Security permission. And the only security levels that a user
can set are those that he himself is a member of.

177-<Jira Administration for Data Center and Server>

 If you do not have the Assign Issues permission, then you won’t see the Assignee field on
the Create or Edit screen and won’t be able to set it.

178-<Jira Administration for Data Center and Server>

 Similarly for the Reporter field. You can only see and set it on the Create or Edit screen if
you have the Modify Reporter permission.

179-<Jira Administration for Data Center and Server>

 View Voters and Watchers permission grants the ability to view the voters and watchers
of an issue. If you do not have this permission, you can see the field itself, but cannot see
who is in it.

180-<Jira Administration for Data Center and Server>

 And Work on Issues permission is needed to work with the Time tracking fields.

181-<Jira Administration for Data Center and Server>

 Project ACME uses 2 issue types: Bug, Task. They share the Default Field Configuration
where only the Summary field is required. New requirements dictate that:
1. Bug should require Priority
2. Tasks should hide Fix Version
3. A new custom field called Department should be available only on Tasks in ACME
project.
4. What configuration changes are required?
5. The solution is to create 2 new field configurations, configure them as needed. Add
them to a field configuration scheme and associate to the project
6. Also, create a new Department custom field and set custom field context to ACME
project and Task issue type
7. Finally, put Department field on the appropriate screens used by the Task issue type.

182-<Jira Administration for Data Center and Server>

 Troubleshoot the correct configuration of a field, considering field context, field
configuration (scheme) and screen (schemes).

183-<Jira Administration for Data Center and Server>

 This objective is all about putting it all together – all that knowledge about system and
custom fields, field configurations, screens, and the other factors that affect field
visibility. So you can figure out why
1. A field may not appear as expected. Here are the reasons:
2. It is not on the right screen. It may have been removed from a screen or never added
in the first place.
3. It could be hidden in the field configuration
4. Or the field context is not for the right project and/or issue type.
5. If it has no value yet, you won’t see it on the View Issue Screen.
6. The user could have hidden it through their Configure Fields setting
7. The user may not have the needed project permission for special fields like Due Date.
And of course, more than one factor may be true in any given scenario.
8. In real world situations, Jira administrators also have at their disposal the “Where is
my field” admin helper tool, which analyzes configurations affecting field visibility.
But for the exam, of course, you need to figure this out for yourself.

184-<Jira Administration for Data Center and Server>

 So let’s say that a user complains that the Region field used to be available and
populated in two projects, INT and EXT. But now it’s no longer available in the EXT
project. The JQL query “project = EXT and Region is not empty” returns zero issues. The
projects share screens. And you definitely know that no one deleted the field contents. So
what could have changed? Let’s take all the possible factors one by one.
1. Does the user have the right permissions? Well, Region is not a system field. So since
it is a custom field, there are no specific project permissions that hide it from the
screens.
2. So this is OK.
3. Does it contain values? Well, we are told that it used to be populated and no one
deleted the contents in the EXT project.
4. So this is OK, too.
5. The Configure Fields user setting
6. is also OK. In fact, it is irrelevant here since we’re trying to figure out why the query
doesn’t even return any results.
7. What about screens? Well, we are told that the projects share screens and the field
presumably still exists in the INT project.
8. So this is OK. And although it is possible that the custom field was removed from the
screens used by the two projects, that still doesn’t explain why the existing field
contents are not showing up and being returned by the query. Even if removed from

185-<Jira Administration for Data Center and Server>

 screens, that would not affect searches.

185-<Enter course name in Notes master>

 That leaves us with Field Configuration and Custom Field Context.
1. And both of these may be the answer to our problem. There are differences between
removing a field from a screen versus hiding a field in the field configuration.
Removing a field won’t delete existing data and won’t affect search or reporting. And
although hiding a field in a field configuration also won’t delete the existing data, the
field will not be viewable, searchable or usable in any way. So the query for the EXT
project and Region would in fact return zero issues, assuming indexing had occurred.
The same is true for custom field context. If the field was available for global context,
or just INT and EXT projects, and then it was changed so that EXT was no longer in
scope of the Region custom field, this would affect search results after a re-index.
Hopefully, this helps you think through the complexity of such a scenario, on the exam
and in the real world.

186-<Jira Administration for Data Center and Server>

 Module 7 is about workflows. This is one of the biggest complexities in Jira, so prepare
yourself for detailed and complex questions on the exam.

187-<Jira Administration for Data Center and Server>

 This module has 3 objectives.

188-<Jira Administration for Data Center and Server>

 The first objective here is to describe core workflow functionality (triggers, conditions,
validators, post-functions, events, properties) and map workflows to issue types.

189-<Jira Administration for Data Center and Server>

 Workflows are the power and the backbone of Jira configurability.
1. They are mapped to issue types in a workflow scheme
2. And workflow schemes are associated with project(s)
3. Like the example here, where Bug issue type is mapped to the Bug Workflow, and
both Tasks and Sub-tasks are mapped to the Task Workflow in a scheme
4. that is associated with one or more projects.

190-<Jira Administration for Data Center and Server>

 In order to configure workflows to meet business requirements, you need to know what
is available at your disposal. There are many workflow-related terms that a Jira
administrator needs to master – what it means and what it does. This includes:
1. Steps
2. Statuses
3. transitions (including common, global, and self-reflecting transitions)
4. Conditions
5. Validators
6. post functions
7. transition screens
8. Events
9. step properties
10. and transition properties
11. Finally, triggers automate a transition through events in Dev Tools. There is not a lot
about triggers on the exam since that requires development tools, which are outside
the scope of this exam. But you should know what a trigger is and how it works in Jira
in a general sense. For conditions, validators, and post functions, you definitely need
to know what is built into Jira.

191-<Jira Administration for Data Center and Server>

 Events includes
1. System events
2. Which are those which happen when issue operations occur, such as creating and
editing an issue, changing the summary, or attaching a file to the issue.
3. Or events fired in workflow transitions, such as Work Started On an Issue, Issue
Resolved or Issue Closed.
4. In addition to system events, Jira allows administrators to create Custom Events that
can also be fired from within workflow transitions as a post function. For example:
5. When an issue is ready for peer review
6. When an issue requires approval
7. When an issue is waiting for customer input.
8. Events are tied to the notification scheme, as we will see in the next module. The
exam will ask you how to configure a notification scheme based on the stated
business requirements. You should know all the system events as well as the purpose
and usage of custom events.

192-<Jira Administration for Data Center and Server>

 Workflow properties can further customize and enrich workflows
1. Step Properties are used to restrict certain actions in a certain status (and possibly to certain
people). Two examples are
2. jira.issue.editable and
3. jira.permission.comment.denied
4. Transition Property examples are
5. Opsbar-sequence to change button order, translating buttons or
6. Including or excluding just some of all the available resolutions in Jira as we learned in an
earlier module. Jira.field.resolution.include is an example.
7. Use properties sparingly, if business requirements warrant them, because they’re hard to
maintain and can easily confuse inexperienced administrators.

193-<Jira Administration for Data Center and Server>

 Transitions move issues from one status to another like the Approve transition which
goes from Pending to Done. The various parts of the Approve transition determine if it is
visible and usable to project users and what happens during and after execution. Let’s
test your knowledge.
1. What happens before everything else?
2. Conditions determine if a transition is seen at all.
3. What happens during the transition?
4. Validators check permissions or input during the transition. And what would you use
if you wanted to gather input from the user at that time?
5. Transition screens can be added to transitions to gather required data from the user
at the time of the transition.
6. And what happens after?
7. Post functions automate various actions after both conditions and validators have
passed
8. including the firing of events.

194-<Jira Administration for Data Center and Server>

 Let’s do this example in quiz style. What would you use to
1. Ask the user to set the Due Date and comment while closing an issued?
2. A transition screen with the Due Date field on it.
3. Comments are added automatically to every transition screen, if the user has
comment permissions.

195-<Jira Administration for Data Center and Server>

 What would you use to
1. Ensure that only managers can see and hence use that transition?
2. A condition
3. And should you use a group or project role?
4. Ideally a project role, as we learned in earlier objectives

196-<Jira Administration for Data Center and Server>

 What would you use to…
1. Let everyone see the transition but only allow those with a permission to execute it
successfully. You might do this for the sake of not confusing users, who expect to see
the transition.
2. You would use a validator. All users can see it and click it, but while it is running, the
transition checks if the user has the required permissions. If not, it will present an
error.

197-<Jira Administration for Data Center and Server>

 And if you needed to
1. Disallow anyone from editing issues after they were approved?
2. You would set the step property “jira.issue.editable” to false on the Approved status.

198-<Jira Administration for Data Center and Server>

 Given business requirements, create new workflows and/or implement appropriate
changes to existing workflows and schemes.

199-<Jira Administration for Data Center and Server>

 Let’s begin with the skills required for this objective.
1. The candidate is expected to be able to create and maintain workflows using the
workflow tools through a web browser. You don’t need to know about editing a
workflow in the XML format
2. You need to know both the diagram and text mode of editing workflows
3. You must be able to interpret business requirements and translate them into
appropriate technical configurations
4. If there are multiple ways to satisfy requirements, you may need to pick the best one
according to best practices and the given scenario.
5. Do we really need a new status, for example.
6. Do we really need to create multiple new transition or use a common or global
transition?
7. How should permission be configured?

200-<Jira Administration for Data Center and Server>

 Some other considerations are:
1. Is a workflow update required to satisfy business requirements or is something else
required instead?
2. Should you create a new workflow or modify an existing one?
3. How many issue types are needed? For example, instead of having two issue types
and two workflows, can we just have a single workflow and a condition?
4. Can I make a particular workflow change by editing an active workflow and
publishing the draft or is a workflow migration needed?

201-<Jira Administration for Data Center and Server>

 1. Inspect the HR Workflow Scheme for this example.
2. The scheme maps both the Request and Task issue types to the single HR workflow,
and the scheme is associated with the HR project.
3. Currently, the user is prompted only for the Resolution when issues are being closed.
Now, the project lead wants to prompt for the Resolution and the Criteria field but
only when closing Requests, because Tasks don’t use the Criteria field at all.
4. Perhaps you’re thinking of separating workflows, so that Tasks can continue to use
the HR workflow as is, but Requests would use a different workflow that uses a
different transition screen during the close transition – that has both Resolution and
Criteria field on it. But remember, what looks like a workflow question may not
actually require a workflow change. And on the exam, you will only see the questions
themselves. It won’t tell you which module or objective that question belongs to. So
you need to analyze the question on its own merit.
5. Can we simply add the Criteria field to the current transition screen and then hide the
field in the field configuration used by Requests? Yes, we can. The transition screen
and therefore the workflow remains the same, but the Criteria field won’t show up on
Requests because the field configuration is hiding it. Is this a better solution? It might
be. Workflows are generally harder to maintain. And there is a good chance that
Requests necessitate different field configurations anyway. You will need to weigh
the decision based on these factors and other information in the exam scenario.

202-<Jira Administration for Data Center and Server>

 Finally, given a scenario, you need to troubleshoot workflow configurations.

203-<Jira Administration for Data Center and Server>

 Workflow configuration and troubleshooting is a big part of a Jira Administrator’s job.
When users approach you with a problem, the root cause may be a design flaw, or it
could be working as designed. Let’s look at various workflow problems. Permissions are
likely culprits. Here are some examples and what to check.
1. If the user cannot see any transitions, check the Transition Issues permission.
2. If the user cannot see one transition, check permissions or project roles in a workflow
condition.
3. If the user cannot drag cards to a particular column on a board, then the transition
condition is probably not being met in the underlying workflow.
4. If no one can edit issues in just one status, check the Step Property
“jira.issue.editable”
5. If some users cannot comment in a particular status, check the Step Property
“jira.permission.comment.*”

204-<Jira Administration for Data Center and Server>

 Here are some possible misconfiguration problems.
1. If the user cannot add / update a required field during a transition, the field may not
be on the transition screen.
2. If the user is not notified when a transition occurs, perhaps the wrong event is being
fired or the user is not listed as an event recipient in the project’s notification scheme.
3. If a saved filter or gadget is returning data errors, perhaps a workflow status was
removed or renamed or the resolution is not being set correctly.
4. If a board column shows no issues, perhaps the status was removed from the
workflow, but the column was not.

205-<Jira Administration for Data Center and Server>

 And a couple more gotchas.
1. If, after editing a workflow, users are reporting problems with other projects and
issue types, then the workflow was probably shared, and you may now need to undo
the changes. Or figure out what to fix. For example, perhaps a condition was added
which references a project role. And membership was not updated correctly in all the
projects that share the workflow.
2. And if the workflow is returning strange errors in the logs, perhaps a Marketplace
workflow app is causing the issues. This scenario is not in the scope of the
certification though.

206-<Jira Administration for Data Center and Server>

 Let’s look at a very common, and detrimental, problem in Jira.
1. A user complains about the inaccuracy of issue counts in a couple statistical gadgets
and reports.
2. Nothing appears to have been resolved despite being in the Closed status.
3. A few issues are counted as resolved when in fact their status reads Open.
4. What’s wrong?
5. The culprit is the Resolution field.
6. If resolved issues are showing as still being open, then the workflow is not setting the
Resolution field.
7. And if open issues are showing as still being resolved, then the workflow is not
clearing the Resolution field.

207-<Jira Administration for Data Center and Server>

 Module 8 is about Setting up Notifications and Email.

208-<Jira Administration for Data Center and Server>

 It has 3 objectives.

209-<Jira Administration for Data Center and Server>

 Let’s begin. Determine an appropriate notification scheme / configuration including
events.

210-<Jira Administration for Data Center and Server>

 Jira sends all kinds of notifications, let’s first recap a few.
1. When users create saved filters and then add filter subscriptions based on them,
whether personal or group, then Jira sends out those periodic subscription emails.
2. Users can also Share issues and filters from within Jira.
3. Users can @ mention others in issue description and comments.
4. Administrations can use the Send Email function.
5. But of course, the most common type of notifications are the ones triggered by events
which are configured in a project’s notification scheme. We looked at system and
custom events in the previous module on workflows and we will put them in context
here.
6. By the way, one often mistaken notion is that issue linking is an issue update event.
But it is not. So linking issues does not trigger notifications.

211-<Jira Administration for Data Center and Server>

 Notification Schemes
1. list all the possible system and custom events in Jira
2. And Map those events to email recipients.
3. They are associated with one or more projects. So they control when an email is sent,
and to whom, in which project
4. Here we see an example of two entries of a notification scheme. The Issue Created
event will send an email to everyone who is listed in the Project Role (Managers) and
the Issue Deleted event will notify all jira-administrators.

212-<Jira Administration for Data Center and Server>

 Notification recipients can vary
1. The default recipients are
2. the current issue Assignees
3. Reporter
4. and any watchers.
5. But you can add many other entries
6. such as current user
7. Project lead and Component Lead
8. User picker and group picker custom Field Values
9. Group, role, single User or Single Email Address
10. Remember best practices dictate that roles are preferred before groups, and groups
are preferred before individual users.

213-<Jira Administration for Data Center and Server>

 Let’s look at the end-to-end process when an event is fired as a post function in a
workflow transition:
1. A user executes a transition
2. Jira fires the event associated with that transition
3. Jira checks the relevant notification scheme
4. It finds the recipient entries listed for that event
5. And then what? Is the email sent right away to those people?
6. No. Jira first checks if those recipients actually have access to the project and the
issue by cross-checking with project permissions and issue-level security, if any. That’s
a very important point.
7. Only after that, Jira sends notifications to the permitted entries listed in that event

214-<Jira Administration for Data Center and Server>

 You need to send an email to the CFO when a capital expense needs approval. But the
CFO should not receive any other notifications about issue events in this project. How do
you configure this? This is a perfect use case for a custom event.Here are the high-level
configuration steps.

1. Create an appropriate custom event through the Events area of Jira administration, if
it doesn’t already exist.
2. In the relevant workflow, update the Approval transition to use that custom event. By
default, when creating a new transition, the transition is set to fire a Generic system
event, but you can change it to the custom event.
3. In the relevant notification scheme, add the CFO and anyone else required into that
custom event.
4. Ensure the CFO has access to the project and its issues

215-<Jira Administration for Data Center and Server>

 The second objective is to troubleshoot a notification scheme or configuration including
events.

216-<Jira Administration for Data Center and Server>

 There are multiple reasons why emails may not be sent out as expected. You need to
know where to look if a user complains that they are not receiving certain emails. This
should be easier if you feel confident with the content of the previous objective. Let’s say
a user reports an email problem. What questions should we ask to narrow the problem?
1. First, is everyone else getting email? Otherwise, this might be a more global issue.
2. Are they receiving it from the relevant project? If not, maybe the notification scheme
has been changed or entries removed, intentionally or by accident.
3. What notifications was the user expecting? This helps you identify the event and
determine if it was related to a workflow transition perhaps.
4. Which recipients are listed in the relevant event?
5. Is the user in the right groups, project roles, or custom fields of type user picker or
group picker?
6. Does the user have the right permissions – to see the project or the particular issue, if
issue-level security is enabled?

217-<Jira Administration for Data Center and Server>

 And don’t forget one more thing.
1. There are two settings in the user profile which are related to receiving notifications.
Could they be the cause of a user’s problem?
2. For example, the “My Changes” setting under preferences. If it is set to “Do not notify
me” then the user will not be notified of his or her own changes.
3. And there is also the Autowatch setting. Autowatch is a feature in Jira that
automatically adds you as a watcher if you create, update, or comment on an issue
(and even if someone mentions you). So if you have the Autowatch feature enabled,
you are likely to get notified about changes to all of the issues you are watching. If a
user is not receiving some expected notifications, perhaps their Autowatch is
disabled.

218-<Jira Administration for Data Center and Server>

 Let’s look at a troubleshooting example.
1. Manager Jane is not receiving notifications when issues are resolved in the DEV
project. Let’s figure out why. During your troubleshooting you have already discovered
that:
2. Jane is in Project Role (Managers)
3. Project Role (Managers) is listed in Issue Resolved event
4. Project Role (Managers) has Browse Projects permission
5. Issue-level security is not enabled. So what else could be wrong?
6. Workflow events. Check what event is being fired when issues are transitioned to a
resolve type status in the workflow. We may assume that the workflow is firing the
Issue Resolved or perhaps the Issue Closed event when it is transitioning to a resolve
or done-type status. But this may not be the case, especially if the workflow was
customized.

219-<Jira Administration for Data Center and Server>

 Identify and troubleshoot the appropriate configuration of an Incoming Mail Handler.

220-<Jira Administration for Data Center and Server>

 For many organizations, email is the preferred, and probably the quickest and easiest,
way of communicating. So Jira offers email integration out-of-the-box in the form of
incoming mail handlers, which can be used to create new issues or comment on existing
issues. Administrators will need to know all the options for an incoming mail handler in
order to configure and troubleshoot them. First, some configuration basics.
1. Jira administrators must first define one or more incoming mail servers. The definition
of a mail server in Jira is a mail host on a mail port with a specific username used to
authenticate against the mail account.
2. Configure the mail hander. Each mail handler has the option of
3. reading from a Mail Server
4. or from Local Files, which is available in both Jira Server and Jira Cloud. The local files
option is generally used for testing and is a useful way to test emails without the
need to interact with a mailbox on the mail server. To use local files, you will need
some basic information in order for the mail handler to successfully parse the file.
5. Each mail handler has a dedicated Jira service for each Jira project. When you create a mail
handler, you will see the corresponding Jira service under the Jira administration
services page. If a mail handler is configured to create issues, then there is a single
Jira project configured for it. Each standard mail handler can only create issues in one
Jira project.
6. In terms of protocols, when connecting to mail servers,

221-<Jira Administration for Data Center and Server>

 7. Jira supports POP and IMAP protocols
8. or their secured equivalent protocols

221-<Enter course name in Notes master>

 Here are some of the features of using mail handlers.
1. You can either Create Issues
2. where the email subject becomes the issue summary
3. And the email body becomes the issue description
4. Or you can add the email as a comment to an existing issue. Jira determines this
based on whether it finds an issue key in the email
5. In both cases, the mail handler also looks for email attachments and can attach files
to the issue.
6. The handler can also match the email sender
7. to a corresponding user in the user directory. The first user found with that email
address in Jira is considered to be the author of the comment. If you have multiple
user directories, then the mail handler will check for the user in order of the user
directories starting from top to bottom.
8. If Jira cannot match an email address, you can enable an option to create a new user
if no match is found.
9. Otherwise, set a default reporter.
10. Of course, you need to ensure that the matched user or default reporter has the
necessary permission to create issues, add comments, and add attachments.

222-<Jira Administration for Data Center and Server>

 What are some common problems?
1. You may encounter problems related to email signatures not being removed when an
issue is created, or a comment is added.
2. Another common problem relates to senders not using their Jira user account’s email
address.
3. Or multiple users with the same email address
4. Also, users may complain about too many emails, so you should tune your notification
schemes and manage watched issues.

223-<Jira Administration for Data Center and Server>

 As an example, let’s see what happens when the email handler processes an email
where:
1. the email subject is empty?
2. Then the issue will not be created because the subject is used as the Issue Summary.
And summary is always mandatory during issue creation.
3. What if the project’s field configuration scheme requires other fields during issue
creation, like Due Date?
4. The issue will still be created, but those fields will need to be set the next time the
issue is edited.

224-<Jira Administration for Data Center and Server>

 Module 9 is Jira Server Administration. You are only expected to know how to manage
Jira from the application interface, but you need to know who to approach with your
server administration needs.

225-<Jira Administration for Data Center and Server>

 This module has 7 objectives.

226-<Jira Administration for Data Center and Server>

 The first objective is to recognize the benefits of having production and non-production
instances.

227-<Jira Administration for Data Center and Server>

 There are numerous benefits of having testing or staging instances. And you should be
able to convince stakeholders at your organization why it is important to set them up,
unless you’re using Jira Cloud, of course, since a test environment is not provided. Every
Jira administrator knows the golden rule – do not test on a production system. Even if
there isn’t a staging concept in Jira, administrators need to know what they should not
do in a production instance. Test environments are great for:
1. Evaluating apps from the Atlassian Marketplace
2. Simulating load testing
3. Testing sign-on when dealing with multiple external user directories
4. Planning upgrades and trying out the new functionality
5. Rehearsing bulk updates
6. or trying out major changes to project setup
7. Keep in mind that test instances sometimes need to be configured differently. For
example, they will need different startup parameters and Base URLs, as well as email
settings. Namely, it is prudent to disable outgoing mail, since you shouldn’t be
sending notifications from a testing instance to your user base. It is also
recommended to use a different color scheme or an additional announcement banner
to make it clear that users are on test instance.

228-<Jira Administration for Data Center and Server>

 Let’s have a look at an example. You just set up a non-production Jira instance. You plan
to test bulk operations and some major changes to several projects and schemes. What
may you wish to disable in that environment?
1. Attachments are a maybe, depending on what you want to test. You will certainly
need them to work properly in order to test an upgrade. But perhaps also to test
changes to attachment-related permissions. Otherwise, you can probably disable
them.
2. Outgoing mail should probably be disabled as mentioned on the previous slide.
Otherwise, those test notifications can be confusing and disrupting for users.

229-<Jira Administration for Data Center and Server>

 Given a scenario, recommend whether or not to upgrade and determine the effects of
roll-back.

230-<Jira Administration for Data Center and Server>

 Plan and test your upgrade well.
1. Because rollbacks are meant to be the very last resort and should only be undertaken
when there is no other better solution. As a Jira Administrator, you are not expected
to perform a roll-back on your own.
2. However, you should know the impacts of a roll-back so you can notify stakeholders.
3. Will there be potential data loss? How much has changed in Jira since the upgrade, in
terms of data and configurations? Is that acceptable? Or instead, is a workaround
available for the problem being experienced after an upgrade?
4. Of course, you must understand the importance of backups and disaster recovery.
Backups need to include:
5. the database
6. the home directory
7. and the application directory

231-<Jira Administration for Data Center and Server>

 So let’s say you are ready to plan a Jira upgrade. What are some high-level
considerations?
1. Research the importance of the upgrade – what are the features and fixes you need? You might
want to consider just upgrading to Long Term Support releases
2. Is a non-production instance available for upgrade testing?
3. Are all your user-installed apps compatible with the new version or is an update available for
them?
4. Are there any API integrations that need to be tested and possibly upgraded, as well?
5. How much downtime is expected and in what timeframe can you schedule the upgrade?
6. Do you have a backup and rollback plan?

232-<Jira Administration for Data Center and Server>

 The next objective is to evaluate the need for re-indexing following a set of modifications
and explain the effects of re-indexing.

233-<Jira Administration for Data Center and Server>

 Every Jira administrator knows the re-indexing message very well. “We recommend that
you perform a re-index, as configuration changes were made to (such and such
configuration) by (so and so) at (whatever time).” However, you don’t always need to take
action immediately, and in fact, the message tells you. “If you have other changes to
make, complete them first so that you don’t perform multiple re-indexes.” So when is the
right time to re-index?
1. Well, it’s important to understand which configuration changes might affect search
results and which can wait for a future re-index. You will see that re-index reminder
each time, but you are the best one to know if you can delay it, especially if you have
other changes to make.
2. Ideally, complete all your changes first and do a single re-index. The re-index process
can be lengthy and disruptive to users, not to mention the potential for index
corruption.
3. In fact, best practices dictate that you make your configuration changes (and hence
the re-index) during periods of low user activity.
4. And note that installing an app might sometimes warrant a re-index, if the app
provides custom fields that need to be calculated, for example.

234-<Jira Administration for Data Center and Server>

 How to re-index means understanding the options.
1. One option is background re-index. This will take longer but will allow users to access
Jira during the re-index. Background index doesn't lock Jira but can impact
performance.
2. The second method is to lock Jira and rebuild the index. Jira will be unavailable to all
users until the re-index is complete. This is faster but may still take a while,
depending on the size of your instance and hardware.
3. You also have the option to re-index just one project. This can be useful if you are
certain that your changes were limited only to that project. For example, you are
certain that the field configuration or the custom fields you modified are used only by
that project.

235-<Jira Administration for Data Center and Server>

 The reason to re-index is that otherwise:
1. you’re going to see inconsistency in the search results. Jira needs to keep the actual
data in the database in line with the indices of that data. One sure sign of index
corruption is when search results show you one thing but looking at particular issues
in their issue UI tells you another.
2. Or when dashboard gadgets display no statistics.
3. And what if you created a new custom field named “Region” and then immediately
ran the query “Region IS empty”? What would you expect to see as the results?
4. There will be no results until you have re-indexed.
5. And what do you do if your index gets corrupted, particularly if that corruption occurs
during re-indexing?
6. You need to understand how to enable index recovery and how it works. Recovery
will replace the current index with the backup and then apply any required index
updates.

236-<Jira Administration for Data Center and Server>

 As our example, let’s look at some of the changes to custom field configuration that
might require a re-index.
1. Creating a new field will prompt for a re-index
2. But adding a new field option will not
3. Deleting an option will
4. But disabling an option will not
5. Setting a default value will not need a re-index
6. But modifying custom field context will
7. And so will hiding fields through the field configuration. This is not a complete list, so
if in doubt, test it out. On a non-production instance, ideally of course.
8. And know that many other Jira configuration changes do not require a re-index, such
as making fields required in field configurations, renaming statuses, etc. That’s why
having real-world administrative experience in Jira is required to pass the exam.

237-<Jira Administration for Data Center and Server>

 Troubleshoot application-level problems with Jira (logging and profiling) and escalate
when appropriate.

238-<Jira Administration for Data Center and Server>

 As wonderful as Jira is, things can and do go wrong. So the product offers many
troubleshooting and support tools through the user interface which Jira administrators are expected
to be familiar with. You may not have all the system-level permissions required to fix a
problem, but you can and should be able to troubleshoot it and narrow down the likely
cause. Here is a list.
1. The System Info page is the “start here, read me” manual for Jira and includes
memory statistics.
2. Database monitoring
3. Integrity checker
4. Logging and profiling which allows you to
5. set log levels for various packages.
6. Know those levels - Trace, Debug, Info, Warn, Error, Fatal or OFF
7. There are troubleshooting and support tools
8. Instance health
9. Log analyzer
10. And the Audit Log

239-<Jira Administration for Data Center and Server>

 But you must also know your limits. You can diagnose memory issues, update log levels
and provide information, but you will probably need help:
1. to update JVM settings
2. to retrieve logs from the server from someone who has server access
3. Or help from the database administrator to change database configurations. If you
know Jira’s available tools, you can start troubleshooting and seek assistance from
others to fix the root of the problem.

240-<Jira Administration for Data Center and Server>

 So if you need to investigate a recent Jira performance problem, where might you start?
1. The System Info page is always a good place, especially the Java VM memory
statistics
2. The Audit Log so you can review recent changes made by others – both the system
audit log and the audit log for installed apps
3. You can use the log analyzer to scan for urgent errors and implement any of the
solutions recommended.
4. And you can also enable logging and profiling and analyze performance traces from
atlassian Jira log, assuming you have system level access or can work with someone
who does.

241-<Jira Administration for Data Center and Server>

 Identify and troubleshoot the appropriate configuration of an outgoing email server.

242-<Jira Administration for Data Center and Server>

 First, a brief overview of the outgoing notification process:
1. An issue change occurs in Jira
2. The Events Sub-system detects the change and fires off an issue event corresponding
to that change
3. The mail listener listens for the event
4. and adds outgoing mail items to the mail queue.
5. Finally the Mail service processes the mail items in the queue

243-<Jira Administration for Data Center and Server>

 And a closer look at the Mail Listener:
1. It analyzes the details of the event to determine the relevant issue
2. It finds the project that the issue belongs to
3. It looks at the Notification Scheme associated with that project
4. to determine who should be notified of the event, but before the sending out the
email notification to the recipients
5. it cross checks the permission scheme and issue security scheme associated with the project.
6. The reason is that email notifications will only be sent to a person who has permission to
view the issue.

244-<Jira Administration for Data Center and Server>

 The configurations of the outgoing email server are:
1. The SMTP host name
2. The port number
3. The timeout
4. The username to connect to the host and password
5. And whether it is enabled or disabled
6. Two potential problems may be that the password for the SMTP username used to
connect to the outgoing mail server has expired. Or perhaps the port has changed.

245-<Jira Administration for Data Center and Server>

 Let’s put all of that together. Here all the things to consider when troubleshooting email.
1. The Outgoing mail server
2. The Mail listener and the mail queue or the error queue
3. Notification schemes and events
4. Project permissions and issue-level security
5. Incoming mail servers and mail handlers for incoming mail
6. And filter subscriptions
7. And don’t forget about the Outgoing and Incoming Mail logs
8. Just remember. Not everything related to mail is a mail problem, at least when it is
first reported by users. It may not be a problem at all, or at least not a problem with
mail itself. Things could be working as designed.

246-<Jira Administration for Data Center and Server>

 As examples, let’s see where you would go to start investigating these various kinds of
problems.
1. Some project users receive email notifications, but others don’t.
2. Since this is project-related and some people are receiving the emails, then this not a
problem with the outgoing mail server settings. It is likely related to project access
and scheme configurations. So you should start by looking at the notification scheme,
events, permissions, issue-level security, and of course the individuals, groups, and
roles that have access to the project.
3. What if issues are not being created from an external inbox?
4. This points to a problem with the incoming mail server and handler. Check the
incoming mail logs.
5. John complains that he isn’t receiving his filter subscriptions.
6. A good question to ask is how he configured the subscription and what schedule he
set. But also is the setting “Email this filter, even if there are no issues found”
disabled? If yes, then subscriptions won’t be sent during the times when there are no
results.
7. But what if no one is receiving any mail?
8. Then check out the mail queue, mail logs, and the outgoing mail configuration.
9. But what if mail delivery is just slow?
10. Checking the queue and logs is good. But it could also be caused by large volumes of

247-<Jira Administration for Data Center and Server>

 bulk updates or filter subscriptions gone wild

247-<Enter course name in Notes master>

 The next objective is given a workflow, describe which attributes will and will not be
imported/exported.

248-<Jira Administration for Data Center and Server>

 The first thing is just to know the basics.
1. That in order to move a workflow between Jira instances (like production and staging,
for example) you need to export and import it.
2. And if your workflow is a masterpiece, you can share it on the Atlassian Marketplace.
Only Jira administrators can export and import marketplace workflows.
3. There are two formats: XML and JWB (or Jira Workflow Bundle) – each with its pros
and cons because not all workflow functionality may be carried over.
4. Jira administrators can export workflows, but only Jira System administrators can
import a workflow from a local instance

249-<Jira Administration for Data Center and Server>

 Depending on the format, certain things will not be exported or imported.
1. Let’s start with XML export.
2. It includes most Conditions, Validators, Post Functions but excludes Statuses, Custom
Fields and Screens
3. Meanwhile, the JWB export format includes Statuses, Custom Fields, Screens, but
excludes most Conditions, Validators and Post Functions. Though during the export,
JIRA will note down all the missing configuration elements.
4. For import
5. the XML format includes most Conditions, Validators, Post Functions and excludes
Statuses, Custom Fields and Screens, so they will need to be reconfigured manually
6. And during JWB import any Statuses that are not configured can be mapped to
another Status or created. Same for Screens and Custom Fields. But most Conditions,
Validators, Post Functions will have to be reconfigured manually

250-<Jira Administration for Data Center and Server>

 Did you catch all that? Let’s see. You want to move a workflow from Test to Prod Jira.
You created a brand new workflow with tons of statuses, custom fields, and screens but
few configurations on the transitions themselves. Which workflow format should you
use?
1. Jira Workflow Bundle (or JWB format) is best suited for the job, based on the previous
slide.

251-<Jira Administration for Data Center and Server>

 The final objective. Given a scenario, assess the impact of user directory order and
configuration.

252-<Jira Administration for Data Center and Server>

 Users can be created in Jira’s internal directory and/or managed in external repositories
and connected and synchronized with Jira.
1. A user directory provides persistent storage for information about users and groups.
2. User information includes the person's full name, username, password, email address
and other personal information.
3. Group information includes the name of the group, the users that belong to the group
and possibly nested groups (or groups that belong to other groups)
4. Jira can source this information from another Jira server and multiple user directories
5. Namely, the Jira Internal Directory
6. Or a corporate directory sourced from supported LDAP providers such as Microsoft
Active Directory or OpenLDAP.
7. The directory order and LDAP permissions matter. Let’s start with the latter.

253-<Jira Administration for Data Center and Server>

 When you add external user directories, you also set LDAP permissions for them.
1. Read Only means that Users, groups and memberships are retrieved from your LDAP
server and cannot be modified in JIRA.
2. Read Only, with Local Groups means that users, groups and memberships are
retrieved from your LDAP server and cannot be modified in JIRA. However, users from
LDAP can be added to groups maintained in JIRA's internal directory. This is a frequent
choice for many organizations.
3. Read/Write means that modifying users, groups and memberships in JIRA will cause
the changes to be applied directly to your LDAP server.
4. But note that your configured LDAP user will need to have modification permissions
on your LDAP server.

254-<Jira Administration for Data Center and Server>

 When you rely on External User Directories, you need to understand that directory order
matters.
1. The search order of the directories is top down
2. This is the order in which they will be searched for authentication and for user and
group information.
3. Changes to users and groups will be made only in the first directory, where the
application has permission to make changes.
4. And the order determines which account "wins" in the case of conflicting accounts
5. For this reason, users should only exist in a single directory.

255-<Jira Administration for Data Center and Server>

 So given a scenario on the exam, you might be asked to recommend directory
configurations, predict an outcome, or troubleshoot user and group authentication issues
based on directory order and LDAP permission settings. As you prepare for this exam
objective, be sure you understand
1. The effects of directory ordering
2. But also what happens if a directory becomes inaccessible? Try disabling a directory
yourself to observe the impact.
3. For example, what happens to group memberships used as part of JQL queries.
4. Understand where are users being created.
5. And what happens if there are duplicate users in two directories? Let’s take this last
one as our example.

256-<Jira Administration for Data Center and Server>

 User Bella exists in the internal Jira directory and a corporate LDAP directory. She has a
different password in each. What happens when Bella logs in?
1. If a user exists in multiple directories, the credentials from the first one will prevail;
that account will be used for authentication. If Bella uses that username/password,
she can login. Otherwise she can’t. So that’s why you should avoid duplicate
usernames across directories.

257-<Jira Administration for Data Center and Server>

 And that brings us to our last module. Administering and Extending Jira.

258-<Jira Administration for Data Center and Server>

 This module has 3 objectives.

259-<Jira Administration for Data Center and Server>

 Compare and contrast the different hosting options of Jira.

260-<Jira Administration for Data Center and Server>

 Test takers need to know the differences between Jira's hosting options, Cloud, Server,
and Data Center. The exam contains questions that describe a company's requirements
and ask you to choose the correct hosting option.
1. Jira Cloud is for those who prefer that Atlassian host, set up, secure and maintain
your products in the cloud for you rather than installing and maintaining products on
your own servers. Some benefits are Fast start-up, reduced costs, no need to upgrade,
security and compliance, and the ability to scale up with confidence since Atlassian
handles the procurement of inventory and storage space.
2. Jira Server is self-hosted single server deployment. So you install, host and run our
products yourself, either on your own hardware or through cloud hosting services like
AWS. You can customize your setup however you'd like. Teams who want to manage
all the details may like the flexibility that Jira Server offers. Customers with strict
data hosting and localization requirements may choose Server, as well.
3. Think of Data Center as server, but at scale. Data Center provides the same
functionality as the server products but have additional capabilities to better serve
enterprise organizations. Data Centers offers Active-active clustering for high
availability. It is optimized for AWS or Azure deployment. Offers SAML 2.0 support,
Atlassian-supported disaster recovery, and project archiving for improved
performance.
4. Bottom line, the feature set and pricing varies between the hosting options so check-

261-<Jira Administration for Data Center and Server>

 out Atlassian’s product guides and documentation.

261-<Enter course name in Notes master>

 1. Let’s pretend you have just been hired at a small start-up company and introduced
them to Jira. They love it and want to get started right away. However, they won’t
have a dedicated Jira administrator. So they don’t want to deal with all the upgrades
and potential security vulnerability fixes that come out. What hosting option is good
for them?
2. Jira Cloud just seems like the best option in this case.
3. Meanwhile, a bank that needs complete control of their environment, data privacy,
clustering, and disaster recovery
4. Should choose Jira Data Center

262-<Jira Administration for Data Center and Server>

 Demonstrate how to appropriately configure issue collectors.

263-<Jira Administration for Data Center and Server>

 Issue collectors remain a part of Jira Administration. You need to know their purpose, and
what they can help you with.
1. Issue collectors allows you to easily gather feedback on any website in the form of
Jira issues
2. Or you can use them to raise bugs
3. Or to present a custom form on a website outside of Jira
4. For users with or without Jira accounts

264-<Jira Administration for Data Center and Server>

 Issue collectors come with a variety of configuration options, so know them all.
1. Name, description, and the issue type that will be used when issues are created by
the collector.
2. The Reporter settings – either a static Reporter account or attempt to match the
submitter’s email address.
3. Whether or not to collect browser info. This collects the environment data of the user,
if they consent to it being collected. This data includes the browser type, screen
resolution, referral header, and URL where the feedback was collected.
4. The trigger text and style.
5. And the collector form template – Got Feedback or Raise a Bug
6. or custom template with custom fields
7. And the message text presented to the user filling out the form.
8. You can only use JavaScript in an issue collector to customize the trigger tab, size,
color, and text. Once you have configured the look and feel of an issue collector,
simply embed the generated HTML or JavaScript in any website. Visitors to your
website will see a trigger they can click on to raise bugs and get a form to fill out
directly in your webapp. That form will create an issue in Jira.

265-<Jira Administration for Data Center and Server>

 Of course, you should also know a bit about troubleshooting issue collectors. As an
example, let’s say you’ve deployed an issue collector, but users receive the error shown
when trying it out. How do you troubleshoot and what could it be?
1. You should head to the Issue Collectors area of Project Settings and take look at the
errors.
2. Very often it is due to required fields not being present
3. or the configured Reporter not having Create Issues permission.

266-<Jira Administration for Data Center and Server>

 Demonstrate how to appropriately use the features of the universal plug-in manager (or
UPM).

267-<Jira Administration for Data Center and Server>

 For this topic, you just need to understand the functionality of the Universal Plugin
Manager at a basic level. You should know the following:
1. You can find new apps which are compatible with your Jira version via the Atlassian
Marketplace.
2. You can manage your previously installed apps, check their version, update them,
enable and disable either the whole app or some of its modules.
3. You can view the Audit Log, which shows who installed, enabled, or disabled apps or
updated license keys.
4. You can do a Jira update check to help you prepare for a Jira update, by checking the
compatibility of current apps with a later version of Jira.
5. You can Enter Safe Mode, which disables all user-installed apps, and makes their
features inaccessible. This can help you troubleshoot problems.

268-<Jira Administration for Data Center and Server>

 You should also just be aware of settings related to apps:
1. whether you want to connect to the Atlassian Marketplace to find new apps or
receive free updates on installed apps
2. whether to allow users to request apps
3. whether to disable users and administrators from receiving app notifications via
email.
4. and whether app updates selected by Atlassian will automatically be downloaded
and installed

269-<Jira Administration for Data Center and Server>

 Here is our final example. Your Jira instance has an issue which might be related to user-
installed apps. Where do you start? How do you troubleshoot?
1. First, check the log messages in the UPM Audit Log for clues.
2. If you’re certain it’s a particular app, you can disable the app or one or more of its
modules.
3. Or you can enter safe mode, but this disables all user-installed apps and makes their
features inaccessible. So make sure you understand the impact.

That was our final objective in our final module.

270-<Jira Administration for Data Center and Server>

 Congratulations on completing this prep for the ACP-100 Jira Server Administration
exam!

271-<Jira Administration for Data Center and Server>

 Please take the survey and give us your feedback.

272-<Jira Administration for Data Center and Server>