ACP-420 common mistakes
ACP-420 · Understand the traps and how to avoid them.
The candidate edits a transition, status, or post function directly on the workflow used by their project and assumes the change is scoped to that one project.
Workflows live in workflow schemes, and a single scheme is typically shared by many projects; the candidate reasons about the project screen they are on rather than the object graph behind it.
What to do instead
Before editing, open the workflow and check its usage ('Used in' / workflow scheme associations). If other projects share it, copy the workflow to a new one, build or reuse a separate workflow scheme, and switch the target project's association before making the change.
The candidate adds a custom field to a screen and then declares the field 'working', without checking which screen scheme the project actually uses or whether the field is hidden in the field configuration.
Jira layers screens into screen schemes and then field configuration schemes on top; the default screen is usually not the one in play, and field configuration can hide a field that the screen displays. The candidate stops at the first object that looks right.
What to do instead
Trace the full chain: project -> field configuration scheme -> field configuration (is the field hidden or required?) and issue type screen scheme -> screen scheme -> screen (create/edit/view). Do the same for the transition screen if the field must be editable mid-workflow.
The candidate creates a new issue type in global settings and then reports that it is missing from the project's Create dialog, or that issue creation fails for that type.
Global issue types are only a catalogue; a company-managed project can only use types listed in its issue type scheme, and the candidate confuses the global list with the project's enabled list.
What to do instead
Add the issue type to the issue type scheme associated with the project (and set a sensible default issue type). Use 'Associate' to swap schemes if the type must not appear in projects sharing the current scheme.
The candidate tries to hide issues from a subset of users by editing the permission scheme, expecting certain issues to disappear for people who should not see them.
Permission schemes grant actions (Browse Projects, Edit Issues) across the whole project; issue-level visibility is a separate mechanism (issue security scheme plus a security level set on each issue). The candidate treats one control as the other.
What to do instead
Create an issue security scheme and its levels, associate it with the project, confirm the relevant users have 'Set Issue Security' so levels can be assigned, and confirm viewers are members of the level. Permission schemes can only make the whole project invisible.
The candidate grants a permission to a group when the requirement is one project only, or adds a person to a group when the permission scheme references a project role, then wonders why the person still cannot act.
Roles and groups are both assignable in permission schemes but have different scope: groups are global and role membership is per project. Candidates also assume adding a user to a role automatically grants them any permission, regardless of the scheme.
What to do instead
For per-project access, grant the permission to a project role in the permission scheme, then add the person to that role in the project's People/Access page (or the global Roles page for the role's default members). Reserve groups for genuinely global access.
The candidate adds a 'Only the assignee can do this' validator and expects the transition button to be hidden or greyed out for other users.
Conditions, validators, and post functions run at different points: conditions control whether the transition is offered, validators block submission with an error, post functions act after the transition. All three look like 'transition rules' in the UI.
What to do instead
Use a condition to control visibility of the transition, a validator to enforce data rules on submit, and a post function for side effects. If the requirement is 'users must not see the option', it is a condition, not a validator.
The candidate adds a new status to a workflow, creates issues in it, and reports that the issues vanished from the board or sit in an 'unmapped' state.
Board columns are defined by the board configuration, not by the workflow; a status that is not mapped to a column has nowhere to render, and the board filter may additionally exclude the issues.
What to do instead
Open board configuration -> Columns and map the status to a column. Then verify the board filter and any board sub-filter return the issues, and confirm the issues' project is one the board is based on.
The candidate builds a dashboard with filters and gadgets on their own account, then reports that colleagues see empty gadgets or a 'filter not found' message.
Filters and dashboards are shared objects; a private filter cannot be resolved for another viewer, so gadgets inherit the filter's visibility. Candidates test only as the owner.
What to do instead
Share the underlying filter with the relevant project or group (requires the global 'Share dashboards and filters' permission), then share the dashboard too. Always verify by logging in as a non-admin test user.
The candidate plans to customise field configurations, workflow schemes, or permission schemes for a team-managed project, or expects to move a company-managed project back to team-managed.
Team-managed projects deliberately use simplified, self-contained configuration with no shared schemes, and the conversion path only runs one way. The candidate applies company-managed mental models uniformly.
What to do instead
Confirm the project type first. If scheme-level control is required, the project must be company-managed; team-managed to company-managed conversion is one-way and irreversible, so choose the project type at creation with the end state in mind.
The candidate tries to delete or rename a workflow scheme, permission scheme, or issue type scheme and hits an error, or deletes a project expecting the underlying schemes to be cleaned up too.
Schemes are independent objects; any association with a project blocks deletion, and deleting or archiving a project leaves its schemes and configurations behind.
What to do instead
Find every project associated with the scheme and reassign those projects to another scheme before deleting. When retiring a project, plan a separate tidy-up pass for orphaned schemes, filters, and boards.