Problem:
When creating a new workflow (e.g., a v2 of an existing approval workflow), administrators cannot configure approval steps until the workflow is active — meaning it must be associated with an issue type in a space and published first.

This forces admins to use a workaround: temporarily associate the new workflow with a project, activate it, configure the approval steps, and then deactivate or reassign it. This adds unnecessary risk and complexity, especially when teams are migrating from one workflow version to another and want to have the new workflow fully configured before cutting over.

Expected behavior:
Administrators should be able to configure approval steps on inactive or draft workflows, so that a new workflow can be fully prepared (including approvals) before being published and associated with a live project.

 

Current workaround:
Temporarily associate the workflow with a different service project to make it active, configure the approval steps, then deactivate it by removing the association. This is error-prone and disruptive to administer at scale.