ACP-100 common mistakes
ACP-100 · Understand the traps and how to avoid them.
Assuming a new project automatically inherits the global permission scheme, notification scheme, and issue security scheme rather than checking the scheme association in project settings.
Candidates memorize the existence of global schemes and conflate 'shared default' with 'automatically applied', especially for notification and issue security schemes, which are often absent by default.
What to do instead
Practice reading a project's scheme associations page and stating which schemes apply and whether they are shared or project-specific; verify each of permission, notification, issue security, workflow, field configuration, and issue type schemes separately.
Treating a project role as a group and expecting role membership to be managed through group administration, or expecting a group added to a role to be editable from the role screen.
Roles and groups serve similar purposes in permission schemes, so candidates blur their administration boundaries and forget that roles are project-scoped actors that can contain groups or users.
What to do instead
Learn the actor model explicitly: permission schemes grant to application access, groups, roles, or single users; role membership is maintained per project under the role's user management, while group membership is maintained globally.
Predicting the wrong effective permission when a user receives a permission through multiple actors, or when a global permission and a project permission both appear relevant.
Candidates apply 'most restrictive wins' logic, but Jira permissions are additive and global permissions govern application-level actions, not project-level issue actions.
What to do instead
Work through permission evaluation as a union of all matching grants, and separate global permissions (e.g., administer Jira, create projects) from project permissions; rehearse with a user who gets a permission only via a role containing a group.
Editing a shared issue type scheme or field configuration scheme and assuming only the current project changes, or expecting a field to appear on a screen after only adding it to the field configuration.
Schemes are shared by default and field configuration controls behavior (required, description, renderer) while screens control visibility; candidates collapse these two layers into one.
What to do instead
Trace the chain explicitly: field is added to a screen, the screen is in a screen scheme, the screen scheme is in an issue type screen scheme, and the project uses that scheme; separately verify field configuration only governs behavior for fields already on screens.
Designing a workflow condition or validator that references a field or status that does not exist on the relevant screen or workflow, then expecting the transition to behave as intended.
Conditions and validators are configured on transitions without checking whether the field is present on the transition screen or whether the status is reachable in the workflow.
What to do instead
For every condition or validator, confirm the referenced field is on the transition screen and the status exists in the workflow; test the transition as a user who should fail and as one who should pass.
Confusing a workflow post function with an automation rule and assigning a task to the wrong tool, e.g., using a post function for a scheduled action or an automation rule for a transition-only guard.
Both can update fields and send notifications, so candidates pick whichever they saw most recently without considering trigger type, scope, and execution context.
What to do instead
Classify by trigger: transition-time field updates, comments, and assignee changes belong to post functions; time-based, cross-project, or multi-issue logic belongs to automation; conditions and validators guard transitions and cannot be replaced by automation for blocking purposes.
Assuming a notification scheme sends email to everyone who can see the issue, or forgetting that a user must also have the relevant permission and a notification event must be mapped.
Candidates treat notification schemes as visibility mirrors, but notifications require an event mapping to an actor plus the recipient having browse permission and a valid email.
What to do instead
Trace notification delivery as event, then scheme mapping, then recipient actor, then permission and email checks; verify with a test user in a group versus a role to see the difference.
Building a filter or dashboard gadget and expecting it to be visible to other users without checking filter sharing and dashboard sharing permissions.
Filters default to private, and dashboards have separate share settings; candidates test only with their own admin account and never verify as a target user.
What to do instead
Always check the filter's shared-with settings and the dashboard's share configuration, and verify gadget results as a non-admin user with only the intended project permissions.
Assuming an app or integration will work after installation without verifying application links, authentication method, and required scopes, or assuming a migration will preserve user-generated content such as attachments and comment authors.
Marketplace apps and external integrations depend on configuration outside the app itself, and migrations commonly lose or remap metadata like authors, dates, and attachments.
What to do instead
For integrations, confirm the link direction, auth type, and permissions end to end with a test issue; for migrations, produce a checklist of entities (issues, comments, attachments, users, history) and verify each after import rather than assuming parity.
Answering configuration questions from memory of a default setup instead of reasoning about the specific scheme chain described in the scenario.
The exam presents scenarios with non-default scheme associations, and candidates pattern-match to the default project configuration they have seen most often.
What to do instead
Adopt a fixed reading routine for each scenario: identify the project, list its schemes, then resolve the question layer by layer (issue type scheme, workflow, field configuration, screen scheme, permission scheme) before selecting an answer.