Summary

Improve the Clone feature so administrators can configure which fields are shown (including custom and required fields) and ensure that required fields are validated during cloning, in line with the standard Create issue experience.

---

Problem

Customers rely heavily on the native Clone action in Jira Cloud as part of their daily workflows. A common scenario is:

• An existing field is later made required via field configuration.

• Users continue to use Clone on older issues that were created before this change.

• During cloning:

• • The Clone dialog does not expose the newly required field.

• • Jira does not perform full required-field validation against the current field configuration / Create screen.

• The cloned issue is successfully created with the now-required field left blank.

Additional limitations:

• There is no way to configure which fields are displayed on the Clone dialog (e.g., to add custom fields or newly required fields).

• The Clone action does not provide a dedicated, configurable “Clone screen” analogous to the Create or Edit screens.

• Required field behavior is inconsistent: fields are enforced on the Create screen, but can effectively be bypassed via Clone.

From the customer’s perspective, this is confusing and feels like a data integrity bug: if a field is required in the configuration, they expect that requirement to be enforced consistently across all creation paths, including cloning.

---

Impact

• Data quality issues:
  Newly cloned issues can be created in a state that violates current field configuration (required fields empty). This undermines trust in the configuration and in Jira’s data integrity.

• Additional manual work:
  Teams must:

• • Manually review cloned issues to ensure required fields are filled, or

• • Add workflow validators and transition screens purely as compensating controls to catch missing fields later.

• User confusion and inconsistent UX:

• • Users are told a field is “required,” but are still able to create cloned issues without it.

• • Different creation paths (Create vs Clone) behave differently, which is hard to explain to non-admin users.

• • Users who are accustomed to Clone expect it to respect the same rules as Create; instead, they encounter hidden gaps and later blockers in the workflow.

• Admin overhead and fragile workarounds:

• • Admins must design and maintain workflow-based or automation-based workarounds simply to enforce consistency:

• • • Transition screens + validators to force completion of fields after clone.

• • • Custom “clone via automation” flows that recreate clone behavior but respect required fields.

• • These workarounds increase configuration complexity and are not as discoverable or intuitive as improving the native Clone feature.

This issue is particularly impactful in environments where:

• Required fields are introduced or changed over time.

• Clone is heavily used as a standard way of creating work (e.g., templated tasks, recurring work items).

• Data completeness is important for reporting, compliance, or downstream integrations.

---

Proposed Solution

Enhance the Jira Cloud Clone feature to be configurable and aligned with Create/Edit behavior. For example:

Configurable Clone Screen

• • Introduce a dedicated, configurable Clone screen, similar to Create/Edit screens.

• • Allow admins to:

• • • Choose which fields appear on the Clone dialog (including custom fields).

• • • Include newly required fields so they are visible and editable at clone time.

• • Support configuration per project/issue type, consistent with other screen schemes.

Enforce Required Fields During Clone

• • Apply the same required-field validation rules during the Clone operation as are applied during Create:

• • • If a field is required in the field configuration / Create screen, cloning should:

• • • • Either prompt the user to fill that field, or

• • • • Block the clone with a clear validation error if it is empty.

• • Ensure this respects current field configurations, even when they change after the original issue was created.

Field Behavior Controls for Clone

• • Provide admin-level options for how specific fields behave during cloning, for example:

• • • Copy as-is (e.g., description, custom fields).

• • • Clear/reset (e.g., dates, assignee, sprint).

• • • Require re-entry (e.g., certain required custom fields that must always be reconsidered).

• • Optionally, provide sensible defaults with the ability to override.

Consistent UX and Messaging

• • Make it clear in the UI when a field is required and being enforced during Clone.

• • Align the Clone experience with the Create issue flow so that users see a consistent and predictable validation model.