[JSM DC] Standard Single User Picker saves successfully for Customers but fails silently for Agents

[shelly888]

We are facing a very unusual issue in our ‌Jira Service Management Data Center‌ environment that started on August 27, affecting all our service projects. 

Platform‌：Jira Service Management Data Center 11.3.2
Upgrade Timeline‌：Completed on August 27, 2026, issue started immediately after the upgrade
Custom Field‌：Standard Jira Single User Picker (not native JSM Participant field)
Automation‌：Field value populated via ScriptRunner 10.5.0 Behaviours
Affected Scope‌：Multiple service projects across the entire instance

This is the exact opposite of the common "Agent works, Customer fails" scenario:

Unlicensed Customers submitting requests via the Customer Portal: The picker loads normally.
Licensed JSM Agents creating requests via native Jira backend: Target user can be searched and selected normally in the picker dropdown, correct accountId is sent in the API payload, but the value is silently dropped and field remains empty on refresh.

What We Have Verified:

✅ No workflow, automation, field configuration or request type changes were deployed before the upgrade
✅ Target user is a valid, active ApplicationUser in internal user directory
✅ No explicit permission errors or validation exceptions found in server logs during Agent submission
✅ Field context and configuration schemes are correctly mapped to all affected projects and issue types
✅ Agent account has global "Browse Users" permission, can manually search and view the target user

Has anyone encountered this exact reversed behavior right after upgrading to JSM DC 11.3.2?
Are there any known bugs in 11.3.2 that make User Picker validation logic behave differently based on user license type?
Could this be a hidden conflict between ScriptRunner 10.5.0 Behaviours and Agent-side form initialization that does not trigger on the simplified Customer Portal render path?

We are currently preparing to migrate the population logic from Behaviours to a post-create Automation rule as a fallback workaround, any shared experience, verified workaround or related bug ticket link would be extremely helpful for us to resolve this quickly.
Thank you all very much for your time and support!

[Carpetland Carpetland]

This does sound like a possible compatibility issue introduced by the upgrade, especially since it affects all projects and started immediately afterward. I would also test disabling the ScriptRunner Behaviour temporarily to confirm whether the Agent-side form initialization is causing the value to be dropped. Moving the logic to a post-create Automation rule sounds like a sensible workaround while investigating further.