How do you keep Jira advice clear when permissions are unknown?

[Ren Takahashi]

A lot of Jira troubleshooting starts with incomplete context. Someone may describe a board, field, automation, or permission problem, but the answer depends on whether the project is company-managed or team-managed, and whether the person asking is a project admin, Jira admin, or site admin.

The pattern I try to use is:

1. State the assumption first.

2. Name the setting area to check.

3. Explain what would change the answer.

4. Avoid telling someone to change production until the project type and permission level are clear.

For example: "If this is a team-managed project, check project settings first. If this is company-managed, a Jira admin may need to check the screen or scheme."

That kind of answer is slower to write, but it is less likely to send someone to the wrong admin page.

How do other people keep advice useful when the permission context is missing?

[Angie_Kroymann_conagra_com]

I would recommend setting up a Confluence space for your Atlassian Administrators.  That way you create a troubleshooting page for issues like this that detail out the protocol to go through when troubleshooting issues.  With regular updates on the page, you can have a robust troubleshooting guide for your administrators to follow.  

[Anne Saunders]

I love a decision tree. 

[Hugo Mora]

@Ren Takahashi your four-step pattern is solid — the thing I'd add is a way to stop needing it so often.

Rather than branching the answer, ask for one artefact that resolves the ambiguity for free: the URL of the page they're looking at. Company-managed Jira Software project URLs carry a /c/ segment (/jira/software/c/projects/ABC/...) that team-managed ones don't. So a pasted link usually tells you the project type without the person having to know the term — which matters, because someone who can't tell you whether it's team- or company-managed also can't reliably answer "are you a project admin?"

A screenshot of the Project settings sidebar does the same job: if they can see Fields, Screens and Permissions as separate items, you're in company-managed territory and probably talking to someone with more than project-level rights.

The other habit I'd suggest: lead with a read-only diagnostic step, not a fork. "Open Project settings and tell me what you see under X" is safe at every permission level, works in both project types, and returns the context you were missing anyway. Then you write one answer instead of two.

When I do have to fork, I try to keep it asymmetric — full answer for the likely case, one line for the other ("if you don't see Screens listed, this is team-managed, come back and I'll adjust"). Two symmetric branches read as twice the work and people pick the wrong one surprisingly often.

Cheers,

--Hugo