Delegating work items to other teams without exposing the entire “leadership” project (i

[Melissa Mleczkowski]

Hi everyone,

we’re using Jira Software Cloud (company-managed projects) and I’m trying to design a permission model for the following scenario:

Context

• We have a restricted “leadership” project where only a small leadership group can see all issues.
• We also have multiple team projects/boards (separate teams) where each team works on their own backlog.

Goal / Problem

Leadership wants to delegate tasks created in the leadership context to one or more teams, while ensuring:

1. Teams must not see the full leadership backlog/project
2. Leadership must be able to track the status/progress after delegation
3. Delegation should support:
   
   • assigning to one team
   • assigning to multiple teams
   • in some cases, visibility limited to a single specific person in a team
4. Teams should ideally be able to work from their own board (or a team view) without constantly switching into the leadership project.
5. We want to avoid a solution that requires creating hundreds of manual security combinations (team A + leadership, team B + leadership, team A+B+leadership, plus user-specific cases, etc.).

What we tried / constraints

• Using separate projects and linking issues doesn’t work well because links are only visible to users who have access to both projects.
• Classic permission schemes / project roles are too coarse.
• Issue Security seems promising, but:
  
  • each issue can only have one security level, and
  • we are unsure how to handle multiple team combinations and person-specific visibility without making it unmanageable.
• We can use Automation, but we want a robust design that reduces human error (e.g., wrong security level set).

Questions

1. Is there a recommended Jira Cloud design pattern for this?
2. Can Issue Security be configured to grant access dynamically based on:
   
   • a multi-group picker (teams) and/or
   • a multi-user picker (specific individuals),
     while still allowing leadership to track everything?
3. If the issue stays in the leadership project (for visibility), how can teams work on it from their own board/view without seeing other leadership issues? (e.g., cross-project boards vs. dashboards vs. filters)
4. What are the main pitfalls/limitations in Jira Cloud for this kind of “delegate without exposing everything” setup?

Any guidance, best practices, or examples would be highly appreciated. Thanks!

[Aaron Pavez _ServiceRocket_]

Hi @Melissa Mleczkowski 

Adding a bit more that can help:

1. Teams must not see the full leadership backlog/project

You will need to play with the permissions scheme and security level. 

Both can be used with groups,roles and single user.

1. Leadership must be able to track the status/progress after delegation

Dashboards and reports

1. Delegation should support:
   
   • assigning to one team  -> not possible. The work item assignee is limited to one user. You might have to use a multipicker user field and reports/dashboards for visibility.
   • assigning to multiple teams -> not possible.
   • in some cases, visibility limited to a single specific person in a team -> security level/permission scheme

1. Teams should ideally be able to work from their own board (or a team view) without constantly switching into the leadership project.

With permissions schemes and security level. permissions to browse all users and then limit with security level.

1 level for external users and 1 for leadership.

Then assign permissions (assign user,edit) to external people so they can work on those work items only.

1. We want to avoid a solution that requires creating hundreds of manual security combinations (team A + leadership, team B + leadership, team A+B+leadership, plus user-specific cases, etc.).

You need a level for leadership (see all) and one for external people (assign it to the work items they will work on, only to those)

More about security level and permissions

https://www.youtube.com/watch?v=qbS5COrug0E

https://www.youtube.com/watch?v=upblsUgoXcU

---

Ideas on how to assign several people to one work item

https://www.youtube.com/watch?v=8DnnuL6WEls

https://community.atlassian.com/forums/Jira-questions/How-can-I-assign-a-task-to-multiple-team-members/qaq-p/2526523

https://community.atlassian.com/forums/App-Central-articles/Best-Practices-for-Assigning-Issues-to-Multiple-Members-in-Jira/ba-p/2528901

---

That being said, if you need multiple assignees on one work item, a third-party app

https://marketplace.atlassian.com/apps/1238408/gpt-multiple-assignees-for-jira?hosting=cloud&tab=overview

https://marketplace.atlassian.com/apps/1230647/multiple-assignees?hosting=cloud&tab=overview

Hope this helps!

Regards!!

[Melissa Mleczkowski]

Thank you for your answer! Is this documentation not saying that it is possible to create a multi picker group issue security and Assignee Security Scheme?

Thats why Im asking

Grant users access to security levels in a work item security scheme | Atlassian Support

[Aaron Pavez _ServiceRocket_]

Yes, you can use a User Picker (multiple users).

1. User custom field value - this grants access to anyone listed in a User picker (single or multi-select) type field on a work item. You’ll be asked which field you want to reference.

Regards

[Melissa Mleczkowski]

Hey @Aaron Pavez _ServiceRocket_  

Thank you very much for your answer! Sorry that I have to ask again, but I am only a Project Admin and only Jira Admins who are external are allowed to make such configurations. They told me that all These things are not possible.

Is it also possible to select multiple groups in a ticket? E.g. group A+B or A+C+D?
Another question that would finally solve my problem is whether the combination of multi group picker and single user (as in your screenshot) is possible like Group A+B and User1, User2? With this I could map everything if the default is that only project members are allowed to see the tickets.

Regards

Melissa

[Aaron Pavez _ServiceRocket_]

> They told me that all These things are not possible.

Well, some of them are not possible as mentioned. But with a little ingenuity, you can do some.

You can mix multiple single groups if needed:

I can add one or multiple groups.

If you need a+b, a+c, you need multiple security schemes.

Regards

[Nikola Perisic]

Welcome @Melissa Mleczkowski 

I see that this is more limited to work items need to be seen depending on the each team. Work item security is designed to have multiple security levels. You can have a single user per security level. You can also use group custom field value. You can create a filter that will only be shared with specific people and therefore that board will only be shown to the leadership (this can be either a group or per user). That way, you will split the work items between leadership and teams. 

Also limiting on who can use the Set Issue Security permission will also point out the ownership of setting the security level.

[Melissa Mleczkowski]

Hey Nicola,

thank You for your answer and your help!

Just to clarify our setup and what we think is critical:

• We operate with multiple projects: one restricted leadership project, and each delivery team has its own separate Jira project.
• We understand that Issue / Work item security is project-scoped (it can restrict visibility within a project, but it does not make an issue from Project A visible in Project B).
• Likewise, boards/filters don’t override permissions — they only show what a user can already browse.

Because leadership should not have access to all issues in each team project, we’re looking for a recommended cross-project delegation pattern: leadership creates a task in the leadership context and delegates it to one or more team projects, while still being able to track progress without gaining visibility into the teams’ full backlogs.

Additionally, if we use Issue Security inside projects (e.g., to limit visibility to a subset of people), it’s important for us to understand whether “group custom field value” supports a multi-group picker (so we can grant visibility to multiple groups/teams without creating many “combination” security levels).

Any best-practice guidance for this multi-project delegation + tracking scenario in Jira Cloud would be appreciated.