Issue Summary

When a Forge app migrates its workflow modules from Connect to Forge (keeping the same module keys), Jira’s bulk Workflows API (POST /rest/api/3/workflows) returns the existing rule instances as forge:* rules but omits the parameters.disabled field from the response — even though the flag is still stored and honoured internally. As a result, any subsequent workflow save via POST /rest/api/3/workflows/update — whether triggered by the app, the workflow editor, or an admin publishing the workflow — writes back the rules without the disabled flag, permanently re-activating every rule that was previously disabled. Affected customers experience validators blocking transitions and conditions hiding transition buttons, with no visible indication of the cause.

Steps to Reproduce

1. Set up a workflow with Forge workflow rules (validators, conditions, post-functions) that were originally created as Connect rules and have some set to disabled (parameters.disabled: "true").
2. Migrate the app’s workflow modules from Connect to Forge, keeping the same module keys.
3. Call POST /rest/api/3/workflows to read the workflow — the rules now appear as forge:* rules, but parameters.disabled is missing from the response. (Note: the transition still works at this point, confirming the flag is still stored.)
4. Call POST /rest/api/3/workflows/update sending back exactly what step 3 returned — or simply open the workflow in the Jira workflow editor and publish it.
5. Observe that the previously disabled rules are now active — conditions hide transitions, validators block them.

Expected Results

POST /rest/api/3/workflows should include parameters.disabled: "true" in the response for rules that have the disabled flag set, regardless of whether they were originally registered as Connect or Forge rules. A round-trip read → write should preserve the disabled state.

Actual Results

POST /rest/api/3/workflows omits parameters.disabled when projecting Connect rule instances as forge:* rules. Any subsequent POST /rest/api/3/workflows/update using this response re-enables all previously disabled rules. Admins cannot detect this — the app’s own UI still shows the rules as disabled, while Jira is actively enforcing them.

Workaround

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