ACP-120 common mistakes
ACP-120 · Understand the traps and how to avoid them.
Adds a custom field to a screen and assumes it will now appear and behave the way it was configured, without checking the field configuration scheme or the field's context.
Candidates treat 'field', 'screen' and 'field configuration' as one setting. In Jira there are three independent layers: the field must be added to the screen (via screen scheme → issue type screen scheme) to be visible, to the field configuration (via field configuration scheme) to control required/description, and its context determines which projects/issue types see the options.
What to do instead
Trace the full chain before testing: custom field → contexts → field configuration scheme → field configuration → screen scheme → issue type screen scheme → project. Use the 'Where is this used' / field association views to confirm each link, and change the layer that actually controls the behaviour you want.
Verifies a permission change by browsing as a site administrator or by re-loading the page as the same admin account, then concludes the permission scheme is correct.
Site admins and project admins bypass or are granted many checks, so admin testing never reproduces what a normal user sees. Permission problems are usually membership problems (wrong group, wrong role, wrong project), which are invisible from an admin session.
What to do instead
Use the Permission Helper on the specific issue/project/permission to see exactly which users, groups and roles grant or block it, and then log in as (or use 'test with a user') a real end user with the same group/role membership as the affected person.
Grants access by adding users to a group when the permission scheme actually grants the permission to a project role (or vice versa), and then reports that the scheme 'does not work'.
Groups are global and shared across all projects; project roles are per-project and are the recommended way to grant project-level access. The two look similar in the permission scheme UI (both appear as grant holders), so candidates add the wrong one.
What to do instead
Read the grant holder in the permission scheme first, then add users to exactly that entity. Prefer project roles for project access, keep groups for global/administrative purposes, and manage role membership in Project settings → People.
Configures an issue-level security scheme but never confirms that the 'Security Level' field is on the Create/Edit screens, so new issues are created with no security level applied.
An issue with no security level set is not restricted by the scheme at all - it is visible to everyone with Browse Projects. Candidates assume enabling the scheme is enough, but the level has to be assigned to each issue.
What to do instead
Add 'Security Level' to the create and edit screens for the affected issue types, optionally set a default level on the scheme, and verify with a restricted user that issues without a level are the only ones visible.
Edits a workflow and expects the change to be live, without publishing the draft or checking which workflow the active workflow scheme maps to that issue type.
Company-managed projects use draft workflows that must be explicitly published, and a project may use a different workflow per issue type via the workflow scheme. Editing the workflow of the wrong issue type, or leaving the draft unpublished, produces 'the change did nothing'.
What to do instead
Check the project's workflow scheme to identify the exact workflow bound to the issue type, edit that workflow, then publish the draft and confirm the scheme is associated with the project. Clear the cache/refresh the issue view to confirm.
Adds a new status to a workflow and transition but does not map it to a board column, then reports that issues 'disappeared' from the board.
Kanban/scrum boards only display issues whose status is mapped to a column; unmapped statuses are hidden by default. The workflow is correct, but the board's column configuration lags behind it.
What to do instead
After changing statuses, open the board configuration → Columns and map the new status to a column (or create one), then verify the issue appears in the correct column.
Creates a team-managed project when the requirement is shared configuration (shared permission schemes, shared workflows, one field configuration across many projects), then discovers the settings cannot be shared.
Team-managed projects are self-contained by design: their workflow, fields, permissions and screens are independent, and many scheme-level settings are not available. Candidates pick the simpler-looking type without mapping it to the administrative requirement.
What to do instead
Decide the project type from the requirement: company-managed (scheme-based) when configuration must be shared, standardised or centrally governed; team-managed when a team needs autonomy and simple settings. Recreating is the only real fix, so choose deliberately at creation time.
Changes notification settings (notification scheme, or 'My Jira notifications') and expects email to start or stop, without confirming which notification scheme the project uses or that the user has not muted the event personally.
Email delivery is the intersection of the project's notification scheme, the user's personal notification preferences, the user's email settings and the mail queue. A project with no scheme uses the default notification scheme, so edits to a different scheme have no effect.
What to do instead
Confirm the notification scheme associated with the project (Project settings → Notifications), then check the individual user's personal notification settings and email visibility. Use the mail queue/logs to verify whether a message was generated at all before changing configuration.
Builds an automation rule that runs 'as the rule actor' and later fails silently when that person leaves the project or loses permissions, and leaves error notifications disabled.
Automation executes with the permissions of its actor, not a superuser. When the actor's access changes, actions such as editing issues, transitioning or assigning are blocked, and without notifications the failures are only visible in the audit log.
What to do instead
Use a dedicated, stable service account (or a rule actor with the needed project permissions) that is documented and not tied to one employee, enable 'notify on rule failure', and check the rule audit log after publishing to confirm executions succeed.
Treats global permissions and project permissions as interchangeable - for example expecting users to appear in pickers or to share filters without the relevant global permissions.
Some capabilities are governed above the project: 'Browse users and groups' controls whether user pickers and mentions resolve, 'Create shared objects' controls sharing filters/dashboards, and 'Administer Jira' controls administration. Project-level grants cannot compensate for a missing global permission.
What to do instead
When a behaviour crosses projects or is not project-scoped, check System → Global permissions for the relevant group membership before touching a permission scheme, and grant the narrowest global permission that satisfies the requirement.