Here you can find what helped me to pass the exam ACP-600 Project Administration in Jira Server a couple of days ago. I hope it helps you too.
Feel free to leave a comment about your experience with the ACP-600 or any other Atlassian certification.
And as a recommendation I do think it works to do what I did and look for the answers yourself in the Atlassian documentation and write them down, as well as doing the labs! But in case you can’t find something, here is all the information to the points in the section “Important concepts to master” from the Exam Topics.
There is also a Part two of this guide with information about the Jira labs here.
Important concepts to master
Exam Topics: Important concepts to master
Which configurations are shared VS unique
Notice: No matter if we create a project using a template or with shared configuration, we will NOT automatically get
components created in our new project, as well as we will NOT share the project description.
When new projects are created from template
When we create a project using one of the templates that come with Jira (eg, templates:
Basic in case of the
Software project type) then 7 schemes will be automatically associated to the new project.
Some of the schemes are unique to the project and some are shared with other projects:
Issue Type Scheme
Issue Type Screen Scheme
Unique schemes can be modified and the changes will not affect any other project.
Changes to shared schemes will affect other projects.
When new projects are created with a shared configuration
When we create a project we can check the option:
Create with shared configuration, in other words: copy an existing project.
All of that project’s schemes will be shared with the new project, which means that any change to a scheme will affect all the projects using that scheme.
Who can change a Project Key, and what are the effects on issues in the project
Only Jira administrators can change the
Jira will start a background re-index once the project key is changed. It is limited to the project issues.
Fix the project entity links: when Jira is connected to another Atlassian application, entity links would have been automatically created between your Jira projects and the relevant “projects” in other applications, e.g. Confluence spaces. If we change the key of a Jira project, we will need to fix the project entity links.
Updating Jira Software agile board filters: if the Jira Software agile boards use the old project key, the board filters may need to be updated to reflect the new project key. Otherwise the board might not display issues from the renamed project.
Which project details can be added and changed by Project Administrators
As a project admin, we can edit our project’s:
- Project lead
- Default assignee
- Sidebar shortcuts
Only Jira administrators can edit the
project type, and
What are the uses of Project Category in Jira
Project categories are useful in large enterprise instances. The uses are:
- Searching for all the issues in a particular project category using JQL.
- Projects sorted by category.
A Jira project can only belong to one category.
What features are available for Jira Software vs Jira Core
Jira Software provides the Project types
Jira Core provides just the Project type
Under those two categories there are available a number of project templates:
Businessproject type has:
Process management, and
A project template is a set of pre-configurations which will be our starting point when we create a new project.
What is the importance of the Browse Projects permission
Browse Projects permission allows users to see projects, view their issues, and search for them in
It is the most important permission and by default, all logged in users with application access have the
Browse Projects permission.
How do combinations of permissions work together to enable specific actions
Combinations of permissions are sometimes needed to complete certain actions.
What permissions are needed to Move Issues
Movie Issues requires
Create Issue permission in the target’s project.
Move Issues permission allows to move issues:
- From one project to another.
- From one issue type to another.
- From one workflow to another workflow within the same project.
What permissions are needed to Edit or Delete All Worklogs
The permissions needed are:
Work On Issues
Edit All Worklogs
Delete All Worklogs
Only relevant if time tracking is enabled.
What permissions are needed to rank issues in the backlog
The project permissions that are required for ranking issues in JIRA Agile Classic Planning Board are:
The same permissions are also required for scheduling issues in JIRA Agile Classic Planning Board.
What permissions are needed to assign issues to yourself
Two permissions are required to assign issues to ourselfes:
Assign issues: permission to assign issues to users. Also allows autocompletion of users in the Assign Issue dropdown.
Assignable user: Permission to be assigned issues. This does not include the ability to assign issues.
What requirements must a user meet in order to use a particular workflow transition
The requirements to use a particular workflow transition are:
Transition Issueproject permission.
- The user has to meet the workflow
Conditionsspecified for the transition, if any.
What is an Issue Collector and what permissions are needed to configure it
Issue Collector allows us to embed the feedback form into a website.
When the user submits the Jira feedback form, an issue is conveniently created in Jira.
The permissions required to configure it is, in case of creating an
- Jira Administrators Global permission
If we are editing an issue collector, we need the following permissions in the project.
Where are all the places you need to look to fully identify what permissions a particular user has
To identify what permissions a particular user has, we look at:
Application access: needed to log in and to use the features of a particular Jira product (Core, Software, Service Desk).
Global permissions: system wide permissions that are granted to groups of users.
Permission schemes: specify what users can do in a particular project. It is a set of users groups or project roles assignments.
Project roles: allow to associate users and/or groups with particular projects.
What are the use cases where it is best to use Project Roles rather than Groups
- Project roles help to reduce the number of schemes.
- Project administrator can manage membership of the project.
- Changes can be made quicker when membership changes.
- Using project roles reduce Jira administrator’s work.
Which business requirements necessitate the use of separate issue types in a project
Issue Types are needed if:
- Issues types have different workflows.
- Issues have different required or hidden fields.
- Issues need different screens when creating, editing or viewing.
- And issues need to be reported on separately.
What is the relationship between screens, screen schemes and issue type screen schemes
screen is just a collection of fields.
Screens are mapped to issue
Edit Issue, and
The mapping of
screens to issue
operations is called
screen schemes and has to be done by Jira Administrators.
The mapping of
screen schemes to
issue types is called
issue type screen scheme.
And then the
issue type screen scheme can be applied to one or more projects.
|Issue Type Screen Scheme|
|Screen Schemes||Mapped to|
|Operation||Screen||Screen scheme||Issue Type|
|CREATE||Screen A||Screen Scheme 1||Bug
|EDIT||Screen B||Screen Scheme 1|
|VIEW||Screen C||Screen Scheme 1|
|Operation||Screen||Screen scheme||Issue Type|
|CREATE||Screen D||Screen Scheme 2||Task|
|EDIT||Screen D||Screen Scheme 2|
|VIEW||Screen D||Screen Scheme 2|
How are they related to field configurations
Field configurations list all the
system fields and the
custom fields available in the JIRA instance to be used in
Field configuration specifies to JIRA what is the behavior of a
field when it is applied to an
issue type. Jira Administrators can change following of a
- Optional or required
- Hidden or visible
- Renderer used by the field
Fields appear in
Transition screens are used when information is needed as an issue moves through its workflow.
Only Jira Administrators can edit
Field configurations and configure
How do you determine the maximum number of screens possibly used in a project (for issue operations and workflow transitions)
The maximum number of screens is = ( 3 * number of issue types ) + number of workflow transitions
issue type can have a maximum of 3 screens, one for each
operation (create, view and edit).
workflow in a project can have 1 transition screen per
Who can make changes to screens, screen schemes and issue type screen schemes
Info: Project administrators can edit their project’s
screens as long as they
- are not shared with any other projects.
- are not a default system screen.
- are not used as a
Info: Only Jira Administrators can…
issue type screen schemes.
What are all the various factors that influence whether a field is visible on a screen
These are the factors that determine if a
field is visible on a
fieldis not on the
screen. Jira Administrators can remove
fieldwas never added.
fieldis hidden in the
field contextmay not be for the right
fieldhas no value yet.
fieldhas been hidden by the user through their
userdoes not have the right permission.
When is it best to use components, and when is it best to use a custom field instead
Components allow us to categorize
issues in large groups, for example:
User Interface, etc.
They are optional in a proect.
Components are used when:
issuemay belong to more than one category.
fieldvalue must be managed by the project administrator
assigneemust be set based on the selected value. Eg: Tom is
Componente Lead, we can set then the
Component Leadas the default asignee.
Custom fields can be also used to categorize, when:
fieldmust have a default value.
fieldoptions are shared across projects.
What are the features, uses, limitations/restrictions of workflow changes, especially the Simplified Workflow
Workflow of the project determines which
statuses ara available in that project.
A project uses either a
Jira Workflow or the
Simplified Workflow to control the transitioning of
issues from one
status to another.
Jira Software projects use the
Simplified Workflow by default.
Simplified Workflow is very basic and it allows
issues to transition from any status to any other status:
global transitions; either from
inside an issue or by dragging issues on the board.
Simplified Workflow can only be used if a board represents a single project.
Who can change the Simplified Workflow? What are the limitations on changes to the Simplified Workflow
Jira Administrators or Project Administrators with
Extended Project Administration.
Users who are both Project Administrators and Board Administrators can change the
Simplified Workflow via the board configuration.
Once we edit a
Simplified Workflow adding
transitions it becomes a
What changes can be performed on statuses and transitions
statuses can be changed.
transitions can also be changed but nothing about
conditions can be modified.
Once we edit a
Simplified Workflow adding
transitions, it is no longer a
Simplified Workflow and becomes a
A customized workflows is usually a more complex workflow. Often it has a specific sequence of steps rather than allowing every status to transition into every other status (global transitions). The Jira administrator may add conditions, user input validation and automated functions to transitions in the workflow.
What things may need to be updated as a result of workflow changes of any kind
status of an
issue may need to be changed if the original
status, which the
issue had, has been removed.
What workflow changes can be done through the board by Board Administrators
- Add columns to a board and map statuses.
- Switch to the
What types of workflow changes can Project Administrators make if Extended Project Administration is enabled
A Project Administrator needs the
Extended Project Administration permission in order to edit
screens in a project.
Project Administrators can edit their project’s workflow if the
- Is not shared with any other projects.
- Is not the Jira default system workflow, which cannot be edited at all.
Project Administrators cannot edit the workflow to the same extent as a Jira Administrator. The restrictions are:
- To add a
status, the status must already exist in the Jira instance i.e. the Project Administrator can’t create new statuses or edit existing statuses. However, if the Project Administrator is also a Board Administrator, they can add a new status to the board (which creates a new status in Jira).
- To remove a
status, the status must not be used by any of the project’s issues.
- The Project Administrator can create, update (name and description) or delete transitions, but they can’t select or update a screen used by the transition, or edit or view a transition’s properties, conditions, validators or post-functions.
Note: You can end up with a lot of statuses if users can freely add their own statuses to their boards in their projects!
How do these settings affect notifications
AutoWatch setting controls whether we automatically watch an issue we create or comment on.
My Changes setting
My Changes setting tells Jira to email us (or not) when we make a change in an
issue and we get included in the list of people to be emailed about it.
Share This Issue
Share This Issue setting sends e-mails to the people we share with.
@Mentions defines whether or not to be notified via e-mail when we are mentioned.
Filter Subscriptions sends us the results of filters on a regular basis.
What are the configuration options for all the out-of-box reports and gadgets (except Agile reports and gadgets)
What is their behavior and expected results
There are three main types of reports: Agile, Issue analysis, and Forecast & management.
Issue analysis and
Forecast & management reports are general reports applicable to all project types for analyzing issues and seeing if your projects are on track.
Issue analysis reports are:
- Average Age Report: Shows the average age of unresolved issues for a project or filter. This helps you see whether your backlog is being kept up to date.
- Created vs. Resolved Issues Report: Maps created issues versus resolved issues over a period of time. This can help you understand whether your overall backlog is growing or shrinking.
- Pie Chart Report: Shows a pie chart of issues for a project/filter grouped by a specified field. This helps you see the breakdown of a set of issues, at a glance.
- Recently Created Issues Report: Shows the number of issues created over a period of time for a project/filter, and how many were resolved. This helps you understand if your team is keeping up with incoming work.
- Resolution Time Report: Shows the length of time taken to resolve a set of issues for a project/filter. This helps you identify trends and incidents that you can investigate further.
- Single Level Group By Report: Shows issues grouped by a particular field for a filter. This helps you group search results by a field and see the overall status of each group.
- Time Since Issues Report: For a date field and project/filter, maps the issues against the date that the field was set. This can help you track how many issues were created, updated, etc, over a period of time.
- Project or saved filter
- Period: Hourly, Daily, Weekly,…
- Days previously: 30
Forecast & management reports are:
- Time Tracking Report: Shows the original and current time estimates for issues in the current project. This can help you determine whether work is on track for those issues.
- User Workload Report: Shows the time estimates for all unresolved issues assigned to a user across projects. This helps you understand the user’s workload better.
- Version Workload Report: Shows the time estimates for all unresolved issues assigned to a version, broken down by user and issues. This helps you understand the remaining work for the version.
- Subtask inclusion
How are valid JQL queries written
We need to know what we are searching for:
- Field name e.g.
- Operator e.g.
- Field value e.g.
Teams in Space
Query: Return ALL issues in the
Teams in Space project
Field Operator Field Value project = “Teams in Space”
What operators and arguments are valid for various JQL functions (e.g. membersOf(), StartOfDay(), WAS, CHANGED, etc.)
The list is pretty long so better to check the official docs:
Which export options are available from the Issue Navigator
Click Export at the top of the page.
Here you see all the different ways you can export your search to reuse in other contexts:
Printable, full content, RSS (Issues), RSS (Comments), CSV (All fields), CSV (Current fields), HTML (All fields), HTML (Current fields), XML, Word, Dashboard Carts
Difference between Workflow Conditions and Workflow Validators
Conditions allow or prevent workflow transitions to be executed. In other words, Transition buttons will not be shown on the
View Issue page if a condition fails, thus the user will not be able to execute the transition.
Using conditions on workflows are best practices and can be used e.g., as follow:
- Allow only members from a specific group to execute a transition.
- An issue has passed through a required status.
- A field contains a required value.
Conditions cannot validate input parameters gathered from the user on the transition’s screen. For that we would use
Validators validate the input after the transition button has been clicked, but before the transition has been performed. When they fail, the issue does not go to the destination status of the transition. The transition’s post functions are not executed.
Example of validators can be:
- Checking that a field has been updated.
- A date is within a specific range.