Current State:

In Jira Service Management Cloud, when a workflow post function is configured on the Create transition to set the Request Type (Customer Request Type) to a specific value (e.g. “Problem”), and an agent creates an issue using that same Request Type on the create screen:

• The issue is created successfully.

• The Request Type field on the resulting issue is sometimes empty, even though:

• • A valid Request Type was selected in the Create dialog, and/or

• • The Create transition post function explicitly sets the Request Type to that same value.

• Validators that require Request Type can pass, but the final created issue can still end up without a Request Type.

• This behaviour has been:

• • Reproduced in the customer’s test environment; and

• • Reproduced on an internal JSM Cloud test instance (see Loom recording: https://www.loom.com/share/d29aef8887354e52b71c839fbb2d9290).

Expected behaviour would be that the created issue always has the configured Request Type when:

• The user selected that Request Type at creation, or

• The workflow post function is configured to set that Request Type on the Create transition.

Instead, there appears to be a defect / race condition where, in this specific scenario (post function setting Request Type to the same value used in creation), the field is not reliably persisted and ends up empty on the created issue.

Proposed Future State:

• When a workflow post function on the Create transition sets Request Type to a specific value, the created issue must always persist that Request Type, regardless of:

• • Whether the same Request Type was selected on the create screen, or

• • Which channel was used (agent create, API, email, etc.).

• Validators and post functions should work together deterministically so that:

• • If the validator passes and the post function sets Request Type,

• • The final created issue always contains the configured Request Type value.

• No combination of “Request Type selected on Create screen” + “post function that sets the same Request Type” should result in the Request Type being empty after creation.

 

Alternative (e.g. Third Party Plugin):

There is no clean third‑party plugin alternative to correct this at the point of issue creation because Request Type is a JSM‑specific field tightly coupled with portal configuration and internal JSM logic.

Current workarounds (none are true replacements for correct core behaviour):

• Automation workaround:

• • Use a Jira Automation rule on Issue created:

• • • Trigger: Issue created

• • • Condition: Issue Type = <Problem> and Request Type is EMPTY

• • • Action: Edit issue → Set Request Type to the desired value (e.g. “Problem”).

• • Optionally add a scheduled rule to backfill Request Type for newly created issues where it is still empty.

• Validator safeguard:

• • Keep a validator on the first transition after creation to block further workflow progress if Request Type is empty.

• Avoid the specific post function pattern:

• • Do not use the “Request Type of the issue will be set to X” post function on Create for the same Request Type that’s being used on the request type itself; rely solely on Automation or manual selection instead.

These are mitigations, not full solutions. The desired outcome is for the core JSM behaviour to correctly persist Request Type in the described scenario without needing additional automation or plugins.