Atlassian ACP-100: Jira Data Center Administration and Its Legacy

ACP-100 was Atlassian's professional-level Jira Administration for Data Center certification. It tested whether an administrator could manage the configuration of a shared Jira environment, diagnose permission and scheme problems, and translate business requirements into changes that would not unintentionally break other projects. The exam belonged to the Data Center branch of Atlassian's certification program rather than the newer cloud-first catalog.

The status matters in 2026: ACP-100 is retired. Atlassian announced the retirement of its Jira Administration for Data Center credential in 2025, with the exam ending on September 11, 2025. People who earned it before retirement may still have a valid credential until the date shown on their certification record, but the exam is no longer a current target for new candidates. Atlassian's active administration track is now centered on Jira Cloud, so anyone encountering the ACP-100 code should treat it as a legacy certification page and use it to understand the skills and history rather than as a current booking destination.

ACP-100 represented the system-wide side of Jira administration

The broader Atlassian certifications catalog has long separated product users, project administrators and system-level administrators because they make different classes of decisions. ACP-100 sat toward the system end of that spectrum. It assumed that the candidate understood how Jira projects work, but its distinctive value was the ability to manage configuration shared across many teams.

That distinction explains why the exam historically expected substantial hands-on experience. Atlassian described the intended audience as administrators with roughly two or more years of practical Jira administration because many questions were scenario based. A candidate might know where a setting lives and still choose the wrong answer if changing it would affect unrelated projects, expose restricted information, or solve a local problem with an unnecessarily global configuration.

A useful starting point for the product vocabulary is a broad Jira fundamentals, but ACP-100 went beyond normal user workflows. It was about understanding the relationships among users, groups, roles, permissions, schemes, fields, screens, workflows, notifications and global settings.

Access, permissions and security formed the largest judgment area

One of the defining ACP-100 skills was being able to reason about who can see and do what in Jira. Application access determines whether a person can use a Jira product at all. Project roles provide project-scoped membership. Groups are often used across multiple configurations. Permission schemes translate those memberships into actions such as browsing projects, creating issues, assigning work, transitioning issues or administering a project.

The difficult part is that these controls overlap. A user can belong to the right project role and still lack the required application access. A permission scheme can grant an action while issue security prevents the user from seeing the individual issue. Workflow conditions can block a transition even when the user has the general transition permission. Comment visibility can introduce another layer of restriction.

ACP-100 therefore rewarded impact analysis. Deactivating a user is not the same as deleting one. Removing a group can affect permission schemes, workflow conditions, JQL filters, restricted comments and dashboard sharing. Changing directory order can alter which user record Jira resolves when identities overlap. The administrator needs to understand the dependency chain before making what appears to be a simple access change.

Project configuration was really a lesson in shared schemes

Jira's flexibility comes from reusable configuration objects. Projects can share workflows, issue type schemes, field configuration schemes, screen schemes, notification schemes and permission schemes. That reuse is powerful because a single well-designed scheme can keep many projects consistent, but it also raises the blast radius of a change.

An administrator who modifies a shared scheme must know every project that consumes it. A request from one team to add a status, hide a field or alter a notification can create side effects elsewhere if the shared object is edited directly. Sometimes the right answer is to create a new scheme or workflow variant; other times the existing shared configuration genuinely should change for everyone.

That is one reason scenario questions matter more than memorizing the administration menus. The exam was testing the decision: should the administrator change a global object, copy and specialize it, delegate the work to a project administrator, or leave the configuration alone because the requirement can be met in a narrower way?

Issue types, fields and screens required end-to-end reasoning

Fields in Jira are not controlled by one setting. A custom field has a type and context. Field configurations can make it required or hidden. Screens determine when and where it is displayed. Screen schemes and issue type screen schemes connect those screens to operations and issue types. A field can exist in the system yet be absent from a particular create or edit experience because one link in that chain does not include it.

ACP-100 scenarios often made candidates trace the entire configuration path. If a field appears for one issue type but not another, the cause may be context rather than the screen. If a field is visible but cannot be populated as expected, its configuration or workflow behavior may be relevant. If several projects share the same scheme, changing a screen may affect more projects than the requestor realizes.

Issue type changes also deserve care because active data already depends on them. Removing, restructuring or migrating issue types can trigger mapping decisions and affect workflows, fields, reports and automation. Strong administrators treat configuration as a live data model, not as a collection of isolated menus.

Workflows and automation connected process design with governance

A workflow expresses allowed movement through statuses, but real behavior depends on much more than the diagram. Conditions control whether a transition is available. Validators decide whether the submitted change is acceptable. Post functions perform actions after a successful transition. Screens can collect information during the transition, and permissions determine whether the user is allowed to perform it.

The exam expected administrators to understand which element belongs where. A business rule that should prevent an invalid transition is different from an action that should happen after the transition succeeds. A status change that must update fields, fire events or assign work requires different configuration from a simple visual workflow change.

Automation adds another decision layer. Even when an automated rule can technically perform an action, administrators should think about scope, triggers, conditions, execution identity and unintended loops. ACP-100 predated some of the cloud automation patterns that dominate current Jira, but the underlying discipline remains useful: automate the smallest reliable process and understand the permissions under which it operates.

Notifications depend on events, schemes and user context

Jira notifications are easy to misdiagnose because several components participate. A workflow transition or issue operation can fire an event. A notification scheme maps that event to recipients. Those recipients may be roles, groups, users, reporters, assignees or watchers, and their ability to receive useful information still depends on whether they can access the issue.

When a user says that an email was not received, changing the mail server is rarely the first sensible step. The administrator should identify whether the event fired, whether the notification scheme includes the intended recipient, whether the project uses the expected scheme, and whether permissions or user preferences affect the result.

This is characteristic of ACP-100 as a whole. Troubleshooting starts with the configuration path and the scope of each control rather than jumping directly to a global change.

Advanced user features mattered because administrators support power users

JQL, dashboards, filters, subscriptions, bulk changes and CSV imports appear to be user features, but administrators need to understand them because these features create dependencies and support issues. A sophisticated JQL query can rely on fields, statuses, groups or functions that change over time. Shared filters can feed dashboards, boards and subscriptions. Bulk operations can alter large sets of issues if the user has the necessary permissions.

CSV import has similar implications. Mapping fields, users, issue types and relationships requires preparation, and importing data into a live Jira environment can expose configuration gaps that were invisible in a small test. ACP-100 expected the administrator to know the prerequisites and likely consequences rather than treating import as a simple file upload.

These topics also explain why practical troubleshooting experience mattered. A candidate who has investigated why a filter returns unexpected issues or why a bulk operation is unavailable is better prepared than someone who memorizes a list of JQL operators without understanding permission context.

ACP-100 and project administration were deliberately different roles

The retired ACP-600 Project Administration in Jira Server concentrated on project-level configuration and the boundaries of delegated administration. ACP-100 assumed that knowledge and extended it into system-wide schemes, security and administration. A project administrator might configure components, versions, boards or permitted project settings; a Jira administrator decides how shared system configuration supports many projects safely.

The current cloud-oriented ACP-620 Managing Jira Projects for Cloud is closer to the project-admin side of that distinction. It focuses on creating and managing Jira Cloud projects, boards, automation and reporting rather than reproducing the old Data Center administrator exam. Likewise, ACP-420 Managing Jira Service Projects for Cloud specializes in Jira Service Management project administration. These are useful adjacent credentials, but neither should be described as the direct equivalent of the retired ACP-100 system-administration exam.

How to use ACP-100 material after retirement

Legacy exam material still has value when it is read with the correct date context. Permission schemes, project roles, issue security, workflows, screens, fields and JQL remain important Jira concepts. Organizations that continue to operate Jira Data Center may also need administrators who understand those mechanics even though the certification is no longer offered.

What should not be carried forward blindly is the assumption that every historical exam objective maps one-to-one to today's cloud product. Atlassian's cloud administration model has evolved, automation capabilities have expanded, and the certification catalog has moved toward current cloud roles. Candidates pursuing a new credential should therefore start from the active Atlassian exam page and use ACP-100 material only as background where the concepts still overlap.

The best reading of ACP-100 in 2026 is as a record of what mature Jira administration requires: understand dependencies before changing shared configuration, reason about access at multiple layers, troubleshoot from evidence, and choose the narrowest configuration change that satisfies the business need without creating collateral effects.

ExamSnap's Atlassian ACP-100 Practice Test Questions and Exam Dumps, study guide, and video training course are complicated in premium bundle. The Exam Updated are monitored by Industry Leading IT Trainers with over 15 years of experience, Atlassian ACP-100 Exam Dumps and Practice Test Questions cover all the Exam Objectives to make sure you pass your exam easily.