It looks like the Service IDs for Affected Services can't be retrieved as a smart value in A4J, making the use of JQL to search for services related to an issue impossible in A4J. Possibly a related or same root cause

For the sake of others who may (by miracle) find this feature request, some helpful links and hints:

1) See: https://community.atlassian.com/t5/Jira-Service-Management/Dynamically-assign-value-to-Affected-Services-field-via-JSM/qaq-p/1728392#M80641

Affected Services though it looks like an Insight Object custom field, and has an Insight schema backing it up, is in fact using Opsgenie API and Opsgenie's service id's for the items. Thankfully Opsgenie service id is stored in the Insight object as an attribute.

We had to use "loop stanzas" as the "shorthand" notation didn't work, kept successfully getting some numeric id value, instead of the Opsgenie Service ID attribute.

2) In our case the duplicate Insight Object custom field Services Affected is based on the same Insight schema, and is presented on the Issue Create scheme, together with dependent Insight Object custom fields.

Automation on create syncs the value to Affected Services.

3) Please note, the Affected Services field does behave differently in UI than the Insight field based on the same Insight schema, as it shows mode details from JSM/Opsgenie, so we preferred to keep that field on the edit and view screens, and hide the "parent" Insight field from these, only displaying it on create screen for the purposes of dependent drop-down functionality.

This does however then require addition setup in Automation to keep Affected Services and the "parent" Insight field in sync in the other direction, so if the affected service changes later in JSM ticket workflow, the dependent Insight field displays correct objects that correspond to the "sub-options". This automation rule is configured to run on Edit and Transition, and not be invoked by other rules.

Obviously, none of this is instantaneous, and is just one major kludge for something that should be so simple, and could have been avoided if the dependent Insight custom field could be dependent on Affected Services directly. 

This request was entered to prevent the need to have a duplicate Insight Object field created in order to have a second Insight Object field use Affected Services on the Issue as a filter.

In my case I had additional details needed by service to be linked to an Issue, however the entire list is difficult to navigate.  The filter option was perfect but it won't work with the build in Affected Services field.  Currently the work around is to duplicate the Affected Services field (keeping accurate with automations) and use that field for the filter.

This request is to make that work around no longer needed.