USEM Exception Management - Questionnaires

[kenmcneil]

In USEM Exception Management when I click on "Vulnerability Response" under Basic Configuration ->Exception Management Configuration to select existing questionnaires the Select Questionnaire box is empty (no records to display) even though the Assessment Workspace shows they are there. This worked in VR, but no longer works after migration. 

When I click on the filter for the Select Questionnaire box it says "Sys ID in"

Before I put in a support ticket I want to make sure that I am not missing a configuration setting. I checked with my SN team and I have admin access for USEM and all of the roles in the documentation.

TIA for your help

[Vikram Reddy]

Hi @kenmcneil,

This looks like a documented platform defect rather than anything missing on your config: it's logged as KB2125175, "Exception Management Configuration form missing Workspace related Questionnaire fields," and it lines up with what your screenshots show.

The tell is that filter chip you found. That Select Questionnaire dialog doesn't just list every active questionnaire, it runs a scripted reference qualifier that resolves to a computed Sys ID in list, which is exactly the chip you saw when you opened the filter. That list gets built from whatever the platform still recognizes as valid exception questionnaires for that config record. After the migration to USEM, questionnaires that render fine in Assessment Workspace aren't being picked up by that same qualifier on the migrated Exception Management Configuration form, so the computed sys_id list comes back empty even though the underlying Assessment Metric Type records are completely intact. It's not that no filter is applied, it's that the filter's computed value list is empty.

Since you've already ruled out roles and admin access at the field/config level, here's what I'd check next before logging a ticket:

• Open the existing questionnaire directly in Assessment Workspace and confirm it's still active and its category wasn't blanked out or re-pointed during the migration.
• Check whether that questionnaire was originally authored in Assessment Workspace versus the older classic assessment designer. Workspace-authored questionnaires are exactly what KB2125175 flags as not resolving on this form.
• Separately, pull up the questionnaire's Assessment Metric Type record (asmt_metric_type) and check its Roles field. That field drives a different, independent restriction: assessment ACLs call hasAssessmentRoles() against metric_type.roles, so if that list is empty or missing your role post-migration it can also hide the record, though this wouldn't produce the "Sys ID in" chip you're seeing, so I'd treat it as a secondary check, not the primary cause.
• Look at the Application Vulnerability row from your second screenshot too. If its picker comes back empty the same way, that confirms this is systemic to the USEM migration rather than specific to one questionnaire.
• As a stopgap, try Design new questionnaire from the top right of that same dialog. A questionnaire created fresh from there gets built in a way the picker already recognizes, so it sidesteps the broken qualifier while you wait on a permanent fix.

Given you've already done the access legwork, I'd skip further self-troubleshooting and open a case citing KB2125175 by number so it routes straight to the team that owns this instead of starting from a generic "questionnaire not showing" ticket. If you can share your USEM plugin version, or whether a freshly built questionnaire picks up correctly

References

• KB2125175: Exception Management Configuration form missing Workspace related Questionnaire fields
• What is the "metric type's roles"? - ServiceNow Community

Thank you,
Vikram Karety
Octigo Solutions INC

[Nazim Ansari]

Hi @kenmcneil 

I was able to reproduce the issue in my instance, and below are my findings.

The questionnaire used for Exception Requests in USEM is sourced from the Assessment Framework.

When you configure Basic Configuration > Exception Management Configuration > Vulnerability Response, the lookup should display the questionnaires created in Assessment Workspace.

In my testing, the Select Questionnaire lookup was also empty, and the filter only showed Sys ID in, even though the questionnaires were visible in Assessment Workspace.

This suggests that the lookup is driven by a reference qualifier that is expected to return a list of eligible questionnaire Sys IDs. If that qualifier returns an empty list, no records are displayed.

Based on my findings, I'd recommend checking the following:

• Ensure the questionnaire is Active and Published.
• Verify the Reference Qualifier on the Questionnaire field to see what criteria it is applying.
• If this started after migrating from VR to USEM, confirm that the migration completed successfully and that the questionnaire mappings were created correctly.
• Check the browser's Network tab for any errors or an empty sys_idIN query when opening the lookup.

If all of the above looks correct, this appears more likely to be a migration issue or a product defect rather than a missing configuration or role.

If you do end up opening a Support case, I'd be interested to know the root cause, as it may help others facing the same issue.

[andy_ojha · Accepted solution]

Hi @kenmcneil 

Sorry we ran into this issue here.

I also saw this issue with the April 2026 release of VR (v30.3.3) in my lab

• On that same instance, the issue was resolved with upgrading to the July patch release VR v30.7.2
• Upgrading VR to the v30.7.2 also automatically upgraded the dependency Smart Assessment Engine (Smart Assessment Core) from 21.0.1 to 22.04 -> and then I saw the issue was resolved

Our Internal Team has confirmed that the issue is related to a dependency on the Smart Assessment Engine (Smart Assessment Core) Store App Version, and has updated the VR Compatibility (Store App) Matrix to reflect this.

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0856498

We could directly upgrade the Smart Assessment Core Store App to 22.0.4 and it should address the issue here. 

Alternatively, upgrading to the July patch release of USEM VR v30.7.2 will also take care of this (it will true-up the dependency here).

Sorry again this happened, @kenmcneil.  I understand the friction this caused, disruption in time, and acknowledge these are quality and documentation improvement areas for us.

Reference - Reproducing in my lab with VR v30.3.3 (April 2026)

Reference - Relief after upgrading VR to v30.7.2

[kenmcneil]

Installed the update and the issue is resolved. Thank you for you assistance.