Is per-team issue security viable in a single JSM project, including a "visible to two teams at once

Question

I'm designing a single company-managed JSM project where several teams work out of the same project but should not see each other's tickets. My plan is to use issue security levels so each team only sees its own work items, with queues layered on top. Normal tickets get a per-team level based on which team they belong to.

The part I want to sanity-check is a "shared" state where one work item must be visible to exactly two teams at once, while staying hidden from everyone else. The scenario is a hand-off: a ticket owned by one team gets passed to another team to action, and during that period both the originating team and the handling team need to see it.

How I intend to model it:

- A group-picker custom field holding the handling team (call it Assignment Team), populated with that team's group.
- A second group-picker custom field holding the originating team (call it Delegating Team), populated with that team's group.
- A single security level (call it "Delegated") whose grantees are: Reporter, plus "group custom field value" pointing at Assignment Team, plus "group custom field value" pointing at Delegating Team.

The idea is that this one level serves any pair of teams, because it reads whichever two groups are sitting in those fields on that specific issue, rather than needing a separate level per team-pairing. Normal tickets keep their single-team level; only hand-off tickets get the "Delegated" level.

Where I'd like community input:

1. Is a single security level with two "group custom field value" grantees a supported and reliable way to express "visible to exactly these two teams," or does dynamic-grantee resolution have limitations I should know about?

Before I go further, I've had a couple of Atlassian partners tell me that issue security "doesn't work well" at this kind of granularity and that the practical answer is to make everything visible to everyone in the project and rely on queues alone. That surprised me, so I'd like to sanity-check it with the community.

I'm keeping the question at the design level on purpose. I'm not asking anyone to debug a specific configuration, just whether the overall approach is sound and supported, or whether there's a reason the "visible to everyone" camp is right.

Nikola Perisic · Answer

Even though you have the automation being set for it that sets the security level, the rule actor should also be the one who has the access for the Set issue security permission.

Other than that, you are safe.

Maria Ciobanu · Answer

Thanks, that's reassuring on point 1.

On the Set Issue Security permission: it's deliberately restricted, users don't have it. The security level is set entirely by automation, so the only identity that needs to set it is the automation actor. I keep the level off the Create and Edit screens so no one can pick or change it manually, and the field is managed by rules only, based on the team fields. That way the "who can set issue security" surface is effectively just the automation, not a list of people.

To explain the scenario (which is more complicated to describe than it was to implement):

I have a custom field called "Assignment Team". When someone sets it to a team other than their own queue, automation changes the security level and fills in a second field called "Delegating Team". This only runs for a newly created linked item, which is intentional.

The use case: as Level 1, I create a task off the main task and hand it to another team. I want to keep visibility on that task I created, but I should not gain visibility on the rest of that team's tasks. That's the crossed visibility I need. When I set "Assignment Team" to the other team, that team becomes the new handler (Assignment Team) and my own queue becomes the "Delegating Team", so the item stays visible to both of us and no one else.

Nikola Perisic · Answer

Hi @Maria Ciobanu

* Yes, because these groups are closed in terms of which users you put in those groups will be seeing the specific work item

Also one thing to keep in mind that issue security also relies on the Security Level field and also the Set issue security permission as well.

* You should limit on who has the Set issue security level permission - not everyone
* Security level field should be on the Create screen since the person who has the permission will also be able to set the Security level.