JSM Cloud: Single automation rule to map Organisations to matching Issue Security Levels (MSP / mult

[Ben Meek]

Hi all,

I’m designing a Jira Service Management Cloud setup for an MSP‑style service project and I’m hitting what looks like a limitation around Issue Security + Automation. I’m hoping other JSM architects/admins can either confirm this, or share a pattern I’ve missed.

Design objective

I have a single JSM project (TITAN) that acts as a multi‑tenant “MSP” service space for many customer organisations (JSM Organisations). For some customers, I want to create a special kind of JSM agent on our side – a “customer admin” – with these properties:

1. They are agents in TITAN only (no access to other projects).

2. Within TITAN, they can only create/view/change tickets for their own customer Organisation, not for any other Organisation.

3. I expect to have hundreds or thousands of customer Organisations over time, so any solution that requires one rule/branch per Organisation (or one security level/automation rule per Organisation) will not scale and is likely to be brittle/error‑prone.

What I’ve implemented so far

• TITAN is a company‑managed JSM project.

• I have a TITAN‑specific permission scheme that limits which users can access TITAN at all.

• I created a group called titan_customer_admin which has JSM agent permissions.

• I created an Issue Security Scheme for TITAN, currently named:
  TITAN TFY Agent Issue Security Scheme for JSM

• It has these security levels:

  • Sensitive Cases

    • Reporter, current assignee, atlassian-addons-project-access

  • Service Desk Team (Default)

    • Reporter, current assignee, project lead, Administrators, Service Desk Team, atlassian-addons-project-access

  • TFY tickets only

    • Intended to limit access to tickets for one specific Organisation (TFY).

    • I have added titan_customer_admin to this level, and also include the usual:

      • Service project customer - portal access

      • atlassian-addons-project-access

      • plus our full internal agent/admin role/group.

So mechanically, this works for TFY if I create an Automation rule like:

• Trigger: Work item created

• Condition: Organizations = TFY

• Action: Set Security level = “TFY tickets only”

Then any agent in titan_customer_admin only sees TFY tickets that have that level. That part is fine.

The problem

What I want is a single, generic automation rule that:

1. On work item created (or transition/field change),

2. Looks at the JSM Organizations field (or the requestor’s org / “raised for” org),

3. And then sets the Security level to the matching org‑specific level, without me having to hard‑code a condition branch for each Organisation.

In other words, conceptually something like:

• Security level = {{issue.Organizations.first.name}} tickets only

…where for each Organisation I’m willing to manually maintain a matching security level:

• Org: TFY → Level: TFY tickets only

• Org: ACME → Level: ACME tickets only

• Org: Contoso → Level: Contoso tickets only

• etc.

I’m not objecting to creating org‑specific security levels; I’m objecting to having to:

• Maintain hundreds/thousands of IF/ELSE branches in one Automation rule, or

• Maintain hundreds/thousands of separate Automation rules (one per Organisation),

both of which are clearly unscalable and brittle.

What I’ve tried / looked at

• Standard Automation patterns like “Set work item security level automatically with Jira Automation”
  (https://support.atlassian.com/automation/kb/automation-or-set-issue-security-level-via-automation-for-jira/)

• Label‑based issue security level KBs.

• Using Jira smart values in Automation.

All of these examples explicitly map some field value to a specific security level, e.g.:

• “If Assignee is X, set Security level = “Level X”

• “If Label contains foo, set Security level = “Foo level”

I haven’t found any example where the Security level name/ID is computed dynamically from another field (e.g. Organisations) so that a single rule can handle arbitrary future orgs without editing the rule configuration itself every time we add a new customer.

My question(s)

1. Is there any way in JSM Cloud Automation to set the “Security level” field dynamically from a smart value derived from Organisations, such that I don’t have to explicitly add a branch per Organisation?
   e.g. Can I set Security level via a smart value like {{issue.Organizations.first.name}} or some transform thereof, assuming I pre‑create matching levels?

2. If not, has anyone found a pattern or workaround that:

   • Still uses Jira’s native Issue Security (not just queues/filters), and

   • Avoids per‑Organisation rule maintenance at scale for this “one project, many Organisations, per‑org customer admin agent” scenario?

3. If the answer is “no, you must explicitly map each Organisation to each Security level in Automation”, I’d appreciate any confirmation from others who’ve explored this at scale, or pointers to patterns where people pushed this further (e.g. via Forge, Connect apps, or external orchestration).

Thanks in advance. I’d really like to confirm whether I’ve hit the hard limit of JSM’s current model here, or whether there’s a smarter way to wire multi‑tenant agent visibility that I haven’t considered

[Trudy Claspill]

Hello @Ben Meek 

Welcome to the Atlassian community.

Are you open to using an app?

Are you willing to maintain an explicit map of security levels to Organizations somewhere as long as it enables you to use a generic automation rule?

[Ben Meek]

Trudy. Thanks for responding to this. 

We are open to anything that works but for almost all access‑control scenarios, actions that change “who can see what” must be performed synchronously (i.e. as part of the transaction), or at least in a way that never over‑exposes data even transiently. Any design that relies on an asynchronous mechanism like Jira automation triggers to tighten visibility after the fact (even if they are implemented in say Forge via event subscriptions) cannot guarantee that Customer A will never see tickets from Customer B. There will always be a non‑zero (and sometimes large) window where data may be more widely visible than most security policy requires. This constraint is clearly documented in the Atlassian KB article below, which clearly states that, on some occasions, Jira Cloud automation “will take an hour or more to execute a trigger.”

Jira Cloud automation triggers are significantly delayed | Jira and Jira Service Management | Atlassian Support

A solution design alternative we have looked at is to use Spaces (fka Projects) to enforce customer separation but this introduces its own (also horrible) constraints of (a) separate work queues for all customers and (b) the technical debt of creating and maintaining space settings separately for all customers. 

[Trudy Claspill]

If you want to get closer to the event of issue creation you might consider third party apps that extend workflow functionality in a manner that would let you add a Post Function to the Create transition. I am thinking that you would have to leverage an app that would provide some level of scripting support, such as Scriptrunner or Jira Miscellaneous Workflow Extensions.

I have not fully thought out these ideas, or tested anything. I'm just brainstorming.

If you wanted to develop an automation rule for this there are a few options you could consider.

One option is to maintain the mapping of Organizations to Security Levels using Assets. You would build an Asset Object for each Organization and one of the attributes of that object would be the Issue Security Level to associate with that Organization. Then in the Automation Rule you could use the information about the Organization from the issue to retrieve the Asset object for that Organization, and pull from that Asset the Security Level to use. You can then use that piece of information to set the Issue Security Level of the individual issue.

If you don't want to maintain a mapping you could consider using the REST API to retrieve the corresponding Issue Security Level. However, without the mapping giving you the ID for the corresponding Issue Security Level you would have to retrieve all the Security Levels for the scheme associated with the project and sort through the output to find the one with the name that matches the Organization, because the APIs don't support retrieving an Issue Security Level based on its name.

If you incorporate an app like ScriptRunner or JMWE you could add a post function to run a custom script to get the corresponding Security Level and set the Level for the issue.

One thing I want to clarify is your use of the term "customer admin agent". The term "customer" is typically used to refer to individuals who are not licensed users of Jira/JSM, and can only interact with creating requests and adding comments to request through the JSM portal or email. The term "agent" typically refers to a person allocated a JSM Agent license and assigned the the Service Desk Team role in a JSM project. Are you trying to restrict visibility of issue for the Customer or for the Agent? Are you using the term "customer agent" to refer to a person who is a licensed JSM Agent who should be restricted to seeing requests in the project based on the customer/organization associated with the request? I think that is what you mean, but I want to make sure that I have accurately understood the context of that role.