Clarification on "Customer Request Type Custom Field" field type in Jira Service Management (Cloud)

[AutomationUIUser]

We are looking for clarification regarding the Customer Request Type Custom Field in Jira Service Management.

Based on our understanding, this field is a system-managed field that is created programmatically by Jira Service Management and cannot be created manually through the Jira UI. However, we could not find any public documentation that explicitly confirms this behavior.

We have the following questions:

1. Is the Customer Request Type Custom Field (com.atlassian.servicedesk:vp-origin) always created programmatically by Jira Service Management?
2. Is it possible to manually create another custom field of the same field type through any supported mechanism (UI, REST API, or otherwise)?

3. In one of our customer's Jira Cloud instances, we observed two custom fields of type Customer Request Type Custom Field:

   • Request Type (locked/system field)
   • Request type (non-locked field)

   Could you please explain under what circumstances this is possible?

4. Could this additional field have been created by Jira Importers Manager (JIM) or another Atlassian migration/import process? If so, is this expected behavior?
5. Is there any public Atlassian documentation describing:
   • how this field is created,
   • its intended behavior,
   • whether duplicate fields of this type can exist, and
   • how migration tools (such as JIM) handle this field during Server/Data Center to Cloud migrations?

The reason for our inquiry is that our application assumed there would always be a single field with the schema com.atlassian.servicedesk:vp-origin, which is normally true. However, in this customer instance, the presence of two such fields caused our application to read the incorrect field.

Any clarification or relevant documentation would be greatly appreciated.

Thank you.

[Marc -Devoteam-]

Hi @AutomationUIUser 

To answer your questions:

1. Field Customer Request Type is not a custom field but a system default field related to JSM
2. No you can't create a custom field like this field
3. So the locked one is the field that is created by default on using the App JSM, the other option is a manual created custom field with the same name
4. This could have been created via the JIM on importing a CSV on Jira admin level or during a migration process. But this is more related to an CSV import action.
5. See your audit log on Jira, this should tel you when this field has been created.

[Gabriela]

The other two replies have the fundamentals right, so I'll build on them for the part that hits your app.

That field type, com.atlassian.servicedesk:vp-origin, is a locked custom field. Locked fields are created and owned by the app that installs them, and an admin can't create, configure or delete one through the UI or the REST API, you can only add it to a screen and view its details (https://confluence.atlassian.com/servicedeskcloud/what-are-locked-custom-fields-1097176337.html). So for your questions 1 and 2, JSM always provisions it programmatically and there's no supported way to hand-make a second one.

That's what makes the unlocked twin explainable. Since nobody can create that field type by hand, an unlocked field carrying the same schema almost always arrived through an import that restored the field definition from the source site, a Server/DC site import or a JIM/CSV import that mapped a column onto it, which is where you and Gor were already pointing. The importer rebuilds the field from the old definition but doesn't hand it the plugin lock, so you're left with the locked one JSM created and an unlocked lookalike from the import. Marc's audit-log tip will give you the exact origin and date for that customer's site.

For the app itself I'd stop matching on com.atlassian.servicedesk:vp-origin, since that's the assumption that broke. Two ways around it that don't care how many vp-origin fields exist. One, of the two fields the locked one is JSM's real field and the value it actually maintains, so resolve to that field's id and treat the unlocked one as noise. Two, and cleaner, pull the request type straight from the Service Desk API, GET /rest/servicedeskapi/request/{issueIdOrKey}?expand=requestType gives you requestTypeId and the expanded requestType (https://developer.atlassian.com/cloud/jira/service-desk/rest/api-group-request/). That reads JSM's own source for the request type and is immune to any duplicate custom fields on the site.

On docs, you're right that there's no public page on the internal creation or the duplicate case. The locked custom fields page above is the closest official reference, and CLOUD-12186 is an open ticket showing this field even gets provisioned on Jira Software-only sites, so its scoping is looser than you'd expect.

[Gor Greyan]

Hi @AutomationUIUser

Based on my experience with Jira Service Management Cloud, the Customer Request Type field is a system-managed field that Jira Service Management creates and maintains automatically. It is used internally to associate Jira issues with JSM request types, and it isn't intended to be created or managed manually through the Jira UI or the public REST APIs.

And in a standard Jira Service Management Cloud instance, you would normally expect to see only a single system-managed field of this type. The scenario you described, where both a locked system field and an unlocked field of the same type exist, is not something that is typically expected or documented.

One possible explanation, I think, is that the additional field was introduced during a migration or import process, from a DC-to-Cloud migration or through migration tools. I haven't found any official Atlassian documentation confirming that this is expected behavior or explaining under which circumstances a duplicate field of this schema may be created. The available documentation focuses on how the field is used by Jira Service Management rather than how it is created internally. If this duplicate field was created during a migration, it may be worth opening a support request with Atlassian to confirm whether this is expected behavior or a migration artifact. Their engineering team should be able to clarify whether this scenario is supported and whether there is guidance for applications that consume this field.