They Can Log In to Jira. Why Is Their Project Missing?

The new colleague can sign in and open Jira, but the delivery project they need is missing. An administrator opens the same link successfully. With work waiting, adding the colleague to an administrator group starts to sound like a practical way to move on.

In the constructed case here, that would solve a much larger problem than the colleague has. They need access to one company-managed delivery project, not permission to administer Jira or browse a restricted finance project.

The cause turns out to be a missed membership: onboarding granted access to the application, while the delivery project grants browsing through a project role the colleague hasn't joined. This is one specific explanation for the symptom, not a claim that every missing project has the same cause. [2][3][4]

The two successful steps already tell us something

Signing in establishes identity for the session. Opening Jira shows that the account can enter the application. Neither step means the person can browse every project inside it. [3][4]

That is why “Jira access provided” can be an accurate administrative update and an incomplete onboarding result. The first team supplied app access; the employee still cannot reach the work their job requires.

The administrator's successful visit proves that another account can see the project. It doesn't prove the colleague's permissions. Keep the affected account, site, project, and failed action fixed while investigating. Switching to a privileged session changes the condition you were trying to explain.

Follow the grant to the account

For a company-managed project, the permission scheme identifies who may perform actions such as browsing its work. A project role or group can be part of how that grant reaches a person. The name of a group alone doesn't tell you that relationship. [2][3]

Our case can be represented simply:

The explanation fits the observations without treating the entire permission model as broken. Once the relevant owner confirms that the colleague belongs in the delivery role, the justified change is the appropriate membership. Broad administration adds powers that this diagnosis doesn't require.

Newer Atlassian screens and documentation may use “space” where a team previously used “project.” Follow the actual role and permission relationship rather than relying on a familiar label.

A successful repair leaves unrelated areas closed

The first test is the route that failed: can the colleague now open the delivery project and a representative work item? The second is equally important: Jira administration and the restricted finance project should remain unavailable.

Those negative checks aren't extra work unrelated to the request. A broad grant could make the first test pass while providing far more than the job needed.

If the project appears but one item remains invisible, the next question has become narrower. Work-item security may restrict particular records. If an item can be read but an action remains unavailable, examine the permission or workflow rule governing that action. Don't keep adding groups as though every remaining symptom disproved the first repair. [1][3]

For onboarding, the lesson is modest and actionable. Where this delivery role is part of the approved job, its membership needs to sit beside app access in the onboarding path. That does not mean copying the same grant to every new employee or contractor; it means checking the work the person was actually expected to reach.

The colleague can now do the intended job, and another administrator can explain why. That is a better result than making the project appear through a privilege nobody planned to maintain.