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

Question

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:

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

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

* 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:

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

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

* 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)

* 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?

* 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?

* 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 P Claspill · Answer

Hello @Ben Meek

Did you decide on a solution for your requirement? If so, can you share that information here so that the community can learn from your experience?

Bob Dalm · Answer

Hi Ben, Why not add a specific user picker custom field to one generic organisation security level.

Then you add an asset for each organisation, and add the relevant admin users and a reference to the JSM organization

Based on the organization of the request, add the admin users to the user picker CF.

You'd end up with one rule for setting access for all organisations, one security level, and you can leverage assets for managing the individual users and a very scalable solution.

Best,

Bob

Trudy P Claspill · Answer

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.