Service Portal Widgets fail when they are in sn_scportal scope. This is due to the plugin com.glideapp.servicecatalog.portal getting loaded too early to install the scoped app.
1) Open the record sp_widget_69deca02675003004b8d794717415a9b.
Observe the record is in the global scope, even though the com.glideapp.servicecatalog.portal plugin creates a scoped app (sn_scportal). Observe the sys_store_app record for sn_scportal does not exist.
2) Delete the sp_widget_69deca02675003004b8d794717415a9b record from the instance.
3) Delete the sys_update_xml record that got recorded for the deletion of sp_widget_69deca02675003004b8d794717415a9b.
4) Reactivate com.glideapp.servicecatalog.portal. Observe now there is a sys_store_app record for sn_scportal. Observe sp_widget_69deca02675003004b8d794717415a9b is recreated, this time it is in the sn_scportal scope and does not work.
This problem has been fixed. If you are able to upgrade, review the Fixed In section to determine the latest version with a permanent fix your instance can be upgraded to.
The pre-Orlando workaround was to clone the OOB widget 'Requests & Approvals' (sp_widget.do?sys_id=69deca02675003004b8d794717415a9b) and change line 212 from Server Script from:
j.variables = new GlobalServiceCatalogUtil().getVariablesForTask(optionsGr, true);
j.variables = new global.GlobalServiceCatalogUtil().getVariablesForTask(optionsGr, true);