Issue Summary

When creating a request via the JSM portal, Jira Service Management currently validates the default values of custom fields that:

• Are present on the internal issue create/view screen, but

• Are not included on the portal request form.

If such a custom field has a default value that is invalid or inactive (for example, a user picker whose default user has been deactivated), the portal request submission fails with a hidden validation error. The customer cannot see which field is causing the failure, and the form cannot be submitted until the default value is updated to a valid active user or removed entirely.

This behavior effectively enforces validation on fields that are invisible to the portal customer and cannot be corrected through the portal UI, resulting in failed request creation and confusing, blocking behavior.

Steps to Reproduce

1. In a JSM project, create or identify a custom field (e.g., a user picker) that supports a default value.

1. Add this custom field to the issue create/view screen for the JSM project.

1. Do not add this field to the corresponding portal request form.

1. Set a default value for this field (e.g., a specific user).

1. Deactivate that user (or otherwise make the default value invalid/inactive).

1. As a portal customer, open the relevant request type in the customer portal.

1. Fill out only the visible required fields and attempt to submit the request.

Expected Results

• If a custom field is not present on the portal request form (i.e., it is only on the internal issue create/view screen), JSM should not validate that field’s default value when creating a request from the portal.

• Specifically, for fields like user pickers (and similar), if the default value refers to an inactive or otherwise invalid user, the portal request should still submit successfully.

• Any validation should be limited to fields actually exposed on the portal form, so customers are not blocked by hidden errors they cannot see or fix.

Actual Results

• The portal request form fails to submit when a non-portal custom field has an invalid default value.

• The validation error is effectively hidden from the portal user; they cannot see or correct the issue because the field is not on the portal form.

• The portal request form will not work again until an admin updates the custom field’s default to a valid active value or removes the default entirely on the internal screen configuration.

Workaround

Currently there is no known workaround for this behavior. A workaround will be added here when available