-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Medium
-
Component/s: Channel - Chat
-
None
-
3
-
Severity 2 - Major
-
48
Issue Summary
When a JSM project’s Request Type system field has the legacy name “Customer Request Type” (instead of “Request Type”), JSM Chat / Assist for Microsoft Teams fails to recognise the field and does not show any requests in the Tickets tab (App Home) for end‑users. The underlying field is the correct locked JSM Request Type system field (com.atlassian.servicedesk:vp-origin), but the integration appears to rely on the human‑readable field name rather than the field’s schema/type, which breaks tenants that still use the legacy naming.
Steps to Reproduce
N/A
Expected Results
– Assist / JSM Chat should correctly resolve the JSM Request Type system field regardless of its legacy name (e.g., “Customer Request Type”, “Service Desk Origin”), based on its schema/type (com.atlassian.servicedesk:vp-origin).
– The Tickets tab in Microsoft Teams should display all relevant requests for the user from the linked JSM project(s), including those where the Request Type field’s underlying name is “Customer Request Type”.
Actual Results
– On instances where the Request Type field’s underlying name is “Customer Request Type”, the Assist / JSM Chat integration fails to map the request type field.
– The Tickets tab in the Assist app in Microsoft Teams does not show any (or shows an incomplete set of) requests for affected users, despite requests existing in the JSM project and having valid request types.
– Dev analysis indicates the integration is expecting the field name to be “Request Type” and does not handle the documented legacy naming variants, causing it to treat the project as if it has no Request Type field.
Workaround
Currently there is no known workaround for this behavior. The JSM Request Type field is a locked system field and cannot be renamed by the customer to match the hard‑coded expectation (“Request Type”) in the integration. A workaround will be added here when available.