ACP-620 common mistakes
ACP-620 · Understand the traps and how to avoid them.
Treating a project's issue type scheme as a list of issue types the project can use, without accounting for the default issue type and the scheme-to-workflow mapping being separate objects.
Candidates memorize that the issue type scheme controls available issue types but forget that the default issue type must be part of the scheme and that each issue type is bound to a workflow through the workflow scheme, so they misdiagnose 'issue type missing' or 'wrong workflow' symptoms.
What to do instead
Before answering, map the chain explicitly: issue type scheme (which types, which default) -> workflow scheme (type-to-workflow mapping) -> workflow (statuses and transitions). Check whether the symptom is a missing type, a wrong default, or an unmapped type that falls back to the default workflow.
Assuming a field is visible on a screen implies it is editable, or that adding a field to a screen makes it appear in the issue view.
Visibility is governed by three layers (field configuration for required/description, screen for presence, and field-level security or permission for view/edit), and candidates collapse them into one.
What to do instead
Diagnose in order: is the field on the relevant screen (create/edit/view/transition)? Is the field configuration hiding it or making it required? Is field-level security or a permission restricting it? Confirm which screen the operation uses, since transition screens differ from edit screens.
Designing a workflow validator or condition that references a field not present on the transition screen, then expecting it to behave as intended.
Candidates focus on the validator logic and forget that validators and post functions execute against the issue state at transition time, and screen presence determines whether a user can supply the needed value.
What to do instead
For each transition, list the screen, the validators, the conditions, and the post functions. If a validator needs a value the user sets, ensure the field is on that transition's screen; otherwise the validator must rely on an existing value or a default set by a post function.
Confusing global permission, project permission, and issue-level security when answering 'why can this user not see the issue'.
All three gate access at different scopes, and candidates check only the project permission scheme or only the issue security scheme.
What to do instead
Walk the hierarchy: global permissions (e.g., browse users, Jira administration) -> project permissions via the permission scheme and the user's roles/groups -> issue security level. Also confirm the user is in the right project role, since roles, not groups alone, often drive project permissions.
Assigning permissions by adding users directly to groups when the project uses role-based permission schemes, causing permissions that appear granted but do not apply.
Candidates equate group membership with project access and miss that permission schemes frequently grant to project roles, whose membership is managed per project.
What to do instead
Check the permission scheme grantee type first (group, role, user, or application access). If grants target roles, verify membership in Project settings -> People, not just group membership in user management.
Building an automation rule with a trigger and action but ignoring the rule's scope (project vs global), conditions, and actor permissions, then concluding automation is broken.
Automation rules run as an actor and are filtered by scope and conditions; candidates test as an admin and assume the rule applies everywhere and to everyone.
What to do instead
Verify rule scope (single project, multiple projects, or global), the actor's permissions on the target project, and any conditions or JQL filters. Reproduce as a user with the same permissions and check the audit log for the rule's execution outcome.
Assuming a notification scheme sends to everyone who can see the issue, rather than only to the grantees configured for that event.
Candidates conflate permission to view with subscription to notifications, and forget that notification schemes list specific recipients per event.
What to do instead
For a notification question, identify the event, then the notification scheme entry for that event and its grantee type (reporter, assignee, group, role, etc.). A user who can view the issue but is not a grantee for that event receives nothing.
Planning a CSV or backup import without checking that referenced users, statuses, issue types, and custom field values already exist in the target instance.
Imports fail or silently drop data when referenced entities are missing, and candidates treat the import wizard as self-contained.
What to do instead
Pre-flight the target: create or map users, ensure the issue type scheme and workflow contain every referenced type and status, and confirm custom field contexts accept the values. For CSV, map columns explicitly and validate a small sample before the full run.
Treating an issue link type as bidirectional and symmetric, or assuming a link direction does not affect JQL and automation.
Link types have inward and outward descriptions, and candidates use the type name without checking which direction a query or rule evaluates.
What to do instead
For link questions, state both directions explicitly (e.g., 'blocks' outward vs 'is blocked by' inward) and write JQL or automation conditions using the correct direction. Verify by inspecting an existing linked issue pair.
Assuming a status name is unique across workflows and that renaming or editing a status affects only one project.
Statuses are global entities shared by workflows, so candidates expect per-project status customization and are surprised when a change ripples.
What to do instead
Check which workflows reference the status before changing it, and prefer adding a new status or a workflow copy over editing a shared one. For project-specific behavior, vary the workflow, not the global status.