We’re experiencing issues with dynamic form field updates on custom catalog items in our San Diego instance. When users select certain options from a dropdown, related fields should populate automatically via client scripts, but they’re staying blank.
The problem occurs specifically with catalog items that have custom UI types (mobile and desktop). Our client script uses g_form.getValue() and g_form.setValue() to manage field dependencies, and it works perfectly in the form designer preview but fails in the actual Service Portal and Platform UI.
function onChange(control, oldValue, newValue) {
var category = g_form.getValue('category');
if (category == 'hardware') {
g_form.setValue('approval_required', 'true');
}
}
We’re getting incomplete submissions because users don’t see the required fields populate. The script scoping is set to global, and we’ve verified the field names match exactly. Has anyone dealt with catalog client script scoping issues across different UI types?
Check your script includes (if any). In San Diego, catalog client scripts with includes sometimes have scoping conflicts when running in Service Portal context versus platform UI. The global scope you mentioned should work, but if you’re calling any script includes or UI scripts, those need proper portal declarations too. You might need to create a separate widget client script for the portal version if the standard client script approach continues to fail.
Adding to Rachel’s point - you might want to verify the script’s execution order. Catalog client scripts run at different lifecycle stages depending on the UI type. In Service Portal, onChange events sometimes fire before the form is fully rendered, causing getValue() to return null. Try adding a null check before your setValue() call. Also check the browser console for any JavaScript errors that might be suppressing the script execution silently.
Have you checked the catalog item’s variable dependencies? Sometimes the issue isn’t the client script itself but the variable configuration. Make sure the target field (approval_required in your case) doesn’t have conflicting UI policies or variable sets that might override your script. Also, in San Diego there were some known issues with catalog client scripts and reference qualifiers - check the release notes for any relevant fixes or workarounds that might apply to your scenario.
I’ve seen this exact behavior before. The issue is likely related to how Service Portal handles client scripts differently than the platform UI. In San Diego, catalog client scripts need to be explicitly configured for portal compatibility. Check if your script has the ‘UI Type’ field set correctly - it should include both ‘Desktop’ and ‘Mobile/Service Portal’ options selected. Also, g_form API methods work differently in portals.