Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Announcing Filter Issue Scope for Insight

A common question we get from people familiar with Insight on Server/DC is when will will Insight for Cloud support the ability to dynamically filter Insight custom fields.

Well, good news! Filter issue scope and placeholders are now available for Insight custom fields as part of the integrated version of Insight for Jira Service Management.

If you’re not familiar with filter issue scope, and wondering what on earth I’m on about, let me explain.


What is filter issue scope?

It’s a configuration option for Insight custom fields that lets you filter the objects shown in the custom field based on other values in the issue. This is done with a combination of IQL and placeholders that pull in the current reporter, assignee, project, summary, due date, custom field values etc.

And it works in the request portal too! You can dynamically filter Insight custom fields based on what’s already selected.


Why is filter issue scope useful?

Let’s say you have a list of laptops in Insight with an owner. When an employee wants to submit an issue involving their laptop you can have a custom field showing the laptops.

Without filter issue scope, the employee will see a list of all laptops, including those belonging to other people. With filter issue scope, you can make the custom field only show the laptops that the employee is the registered owner of which is much more user friendly.


Example configuration:

How to configure - we set the filter issue scope to only show laptops with an Owner whose Jira User account matches that of the reporter of the issue.

”Owner” is an attribute on the “Laptop” object type in Insight which links to an “Employee“ object type.
”Jira user” is an attribute on the “Employee” object type that stores the Jira user profile of the employee.


Screenshot 2021-06-30 at 13.32.17.png


In Action:


Filter issue scope.gif

Other Examples:

Another example use case is for requesting new hardware. For example, if the requestor selects a model of laptop they want, another custom field can be used to show all laptops of that model type that are in stock in your inventory. So the agent doesn’t need to go into Insight to check available stock.

In this configuration, customfield_10236 is our custom field where the customer selects their desired laptop model. 

Screenshot 2021-06-30 at 13.31.50.png

Other common use cases for this, is to have a series of custom fields that narrow down a selection. For example, if you select an ‘affected application’ a following ‘affected infrastructure’ custom field could be set to only show configuration items that are related to the selected application.


Lisa Förstberg
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Oct 09, 2021

Fantastic news!  am I right to understand that filter issue scope does not work in automations yet?

Mikael Sandberg
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Dec 03, 2021

Does this also work with hidden fields on the form? Our use case would be to have a hidden location field and then use that to filter out what objects the user should see. That would allow us to use the same field on different request types based on location.

Like Dirk Ronsmans likes this
Dirk Ronsmans
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Dec 07, 2021

@Mikael Sandberg , @Charlotte Nicolaou 

I've currently got a couple of support tickets open for it. It seems that a hidden field does not have it's value already set on the screen but get's the value when the form is submitted. So for me the value doesn't get added in my query.

However, even when it's not hidden it still doesn't seem to get the value or at least it doesn't work as expected (for me) with select or text custom fields. (but maybe I'm missing on how to get the value from the field and it's different than using the placeholder ${customfield_xxxxx} ?)

i'm still hoping they will allow me to just add a (hidden) text field on my request form that contains my entire query so I can really filter the field based on the Request Type.

Lastly, it does seem to work fine with visible Insight fields that are referencing each other but you can't hide a Insight custom field on Cloud which also means, no default value..

So the basic functionality seems to work "referencing 2 insight custom fields between eachother and also some predefined placeholders like reporter" but other than that the more exotic use cases stump me.

Like # people like this

yap, I also have the same question , I need filter insgiht object by Request Type . but event is set the default value on it for hidden field or use scriptrunner set the default value . 
the insight object filed can't work before the ticket created. 

Like # people like this

I've been trying to use this to get the manager of the reporter but it doesn't seem to be working. Any ideas about how to do this?

Pretty stupid that the "raise this request on behalf of" doesn't display on a customer user, only agents!!

AQL to custom field doesn't work

The last information I had was that the filter function only works with other assets (insight fileld). Is there any change here in the meantime?

@Daniel Ebener 


I have an Insight field filtering on a select list, you just have to have the same string attached to your object at the Insight end


Insight field Name - Development Team:

object having outR(Name in (${${0}})) and Active = True


I have a select field called Queue, I have an attribute in my Development Team Insight object type called Queue, the attribute is pointing at another Insight object type called 'Queue'. basically I 1:1 map the options I have in the Queue field, to objects in the Queue object type at the Insight side. So when someone selects the Queue in the Queue select list field, it refines the Development Teams in the Development Team Insight field

standard customer users do not have access to the field raise request on behalf of.  The AQL doesn't work on custom fields as I raised this last October and still awaiting it to be fixed.

Yeh it's a big shame reference fields and IQL referencing or placeholders in general don't work for hidden fields on a portal form, I do imagine now it's integrated with JSM that we'll see a lot of improvements. Personally I'd also like to see the post function conditions have the option to use jql instead of just Groovy, especially as it doesn't even support Groovy expressions and requires the full script, I just use JMWE instead, way easier.

Is it possible for us to define Insight Object attribute value?






Filter Scope (IQL): ObjectType = ${customfield_10200.attribute("TestColumn")}

Expected Result:

Filter Scope (IQL): ObjectType = "Testing"

Is it possible?

Sounds like if you're just trying to reference another field you could just keep it simple by doing


Filter Scope (IQL):

objecttype = X

Filter Issue Scope (IQL): object having inR(Key in ${customfield_xxxx})

For example I use a different Insight field for a few portal forms that govern the top level category, then I use the same Insight field on ALL of those forms called 'Request Sub Category' and it's able to present the relevant objects with


Filter Issue Scope (IQL): Object HAVING outR(Key in (${customfield_17700},${customfield_17702},${customfield_17703},${customfield_17711},${customfield_17712},${customfield_17800}))


Where all the custom field ID's are the various top level category field Id's I have on my many forms.

I have an object type called Software with the text fields Product Name and Title.

Values could be, for example:

Product Name, Title, Appears in Catalog

Visio, Visio Professional 2019, True

Visio, Visio 365, False

Visio, Visio Viewer, False


I've set up my Software Request issue with one Insight objects field referencing all the fields where Appears in Catalog = true. 

I'd like to set up a second Insight objects field whose Product Name is the same as the first field.  So far I haven't gotten it working.  I thought one of these would work for my Filter Issue Scope:

"Product Name" = ${customfield_14800."Product Name"}   
"Product Name" = ${customfield_14800."Product Name"${0}}   

Is this doable or will I need to create a new object type of just Product Names and then set up my existing object type with the Product Name field defined as a reference?


Log in or Sign up to comment
AUG Leaders

Atlassian Community Events