Updating Jira Workflow Integrations After the Draft API Removal

Jira workflow integrations often need to inspect more than the workflow currently used by an issue. An app might read transition rules, update a post function, or remove a validator as part of an administrative process. Some integrations also distinguish between active and draft workflows when deciding which configuration to modify.

That last part needs attention. Atlassian removed draft-workflow support from the Jira Cloud Workflow transition rules APIs on November 2, 2026. Requests that still include the draft parameter now receive an HTTP 400 response, and WorkflowId objects no longer contain the draft attribute.

This change is narrower than it might first appear. Jira has not removed draft workflow schemes. The change applies specifically to the APIs used by Connect and Forge apps to read and manage workflow transition rule configurations.

For teams maintaining Jira integrations, the main task is to remove the old draft-based assumptions and review how the application identifies workflows before it reads or updates their rules.

What Changed in the Workflow Rules APIs?

The affected API group contains three operations:

Operation	Endpoint	Purpose
Get rule configurations	`GET /rest/api/3/workflow/rule/config`	Reads workflow transition rules
Update rule configurations	`PUT /rest/api/3/workflow/rule/config`	Updates rules created by the calling app
Delete rule configurations	`PUT /rest/api/3/workflow/rule/config/delete`	Deletes supported rules created by a Connect app

Before the removal, integrations could use the draft query parameter when retrieving rule configurations. The WorkflowId object also included a draft property to distinguish between a draft and a non-draft workflow.

For example, an older request might look like this:

GET /rest/api/3/workflow/rule/config?types=postfunction&draft=true

An update request could include a workflow identifier like this:

{
  "workflowId": {
    "name": "Internal Support Workflow",
    "draft": true
  }
}

That approach is no longer supported. Sending the removed parameter results in a bad-request response, and applications must not depend on the draft property being returned in workflow identifiers.

The important point is that removing the parameter is not simply a matter of changing true to false. The application must stop using the old draft-versus-active distinction in these rule API calls.

Find the Old Draft References Before Changing the Code

Start by searching the integration's source code for draft, especially around Jira workflow API requests and request-body models.

Look beyond the URL. The property might be added by a shared TypeScript interface, a configuration builder, or a helper that prepares workflow identifiers.

For example, an application may have a model similar to this:

interface WorkflowId {
  name: string;
  draft: boolean;
}

It may also have a helper that constructs the request:

function createWorkflowId(
  name: string,
  isDraft: boolean
): WorkflowId {
  return {
    name,
    draft: isDraft
  };
}

Both parts reflect the old API contract. If the helper is used by several services, changing only one API call will leave other requests vulnerable to the same failure.

Update the model to match the supported request structure:

interface WorkflowId {
  name: string;
}

function createWorkflowId(name: string): WorkflowId {
  return { name };
}

Then review every place where the application passes this object to Jira.

It is also worth checking environment variables and stored configuration. Some integrations keep a workflow's draft state in a database or deployment configuration. That value might still be useful for an application's own business logic, but it should no longer be sent as part of the Workflow Rules API request.

Update the Workflow Rule Retrieval Request

The retrieval endpoint still exists. What changed is the ability to filter the results using the draft parameter.

A Forge app can continue using requestJira to retrieve rule configurations. For example:

import { requestJira } from "@forge/bridge";

async function getWorkflowRules() {
  const response = await requestJira(
    "/rest/api/3/workflow/rule/config?types=postfunction",
    {
      headers: {
        Accept: "application/json"
      }
    }
  );

  if (!response.ok) {
    const errorBody = await response.text();

    throw new Error(
      `Unable to retrieve workflow rules: ${response.status} ${errorBody}`
    );
  }

  return await response.json();
}

Notice that the request does not include draft=true or draft=false.

The response contains workflow information and its associated rule configurations. An integration should use the returned workflow identifier according to the current API contract rather than expecting a draft-state property.

There is another detail worth checking: the endpoint returns a paginated result. An integration that processes every workflow should not assume that one response contains the complete collection. Use the pagination information returned by Jira to retrieve subsequent pages.

The types parameter is required. Other filters, such as rule keys and workflow names, can help reduce the amount of data returned when the application only needs particular rules.

Remove the Draft Property From Update Requests

The update endpoint supports configuration changes for post functions, conditions, and validators created by the calling Connect or Forge app.

An older integration may build its update payload with a draft property:

const payload = {
  workflows: [
    {
      workflowId: {
        name: "Internal Support Workflow",
        draft: false
      },
      postFunctions: [
        {
          id: "b4d6cbdc-59f5-11e9-8647-d663bd873d93",
          configuration: {
            disabled: false,
            value: "{\"color\":\"red\"}"
          }
        }
      ]
    }
  ]
};

The updated payload should omit that property:

const payload = {
  workflows: [
    {
      workflowId: {
        name: "Internal Support Workflow"
      },
      postFunctions: [
        {
          id: "b4d6cbdc-59f5-11e9-8647-d663bd873d93",
          configuration: {
            disabled: false,
            value: "{\"color\":\"red\"}"
          }
        }
      ]
    }
  ]
};

The application can then submit the request:

async function updateWorkflowRules(payload) {
  const response = await requestJira(
    "/rest/api/3/workflow/rule/config",
    {
      method: "PUT",
      headers: {
        Accept: "application/json",
        "Content-Type": "application/json"
      },
      body: JSON.stringify(payload)
    }
  );

  const result = await response.json();

  if (!response.ok) {
    throw new Error(
      `Workflow rule update failed: ${response.status} ${JSON.stringify(result)}`
    );
  }

  return result;
}

Do not treat an HTTP 200 response as proof that every rule was updated successfully. Jira can return an update result containing errors for individual workflows or rules. Inspect the response's updateResults, ruleUpdateErrors, and updateErrors fields where applicable.

That distinction is important for integrations that update several workflows in one request. A successful HTTP response does not necessarily mean that every requested configuration change succeeded.

Do Not Confuse Workflow Rules With Workflow Scheme Drafts

This is where a rushed migration can cause unnecessary changes.

Jira uses the word draft in more than one workflow-related context. The November 2 removal concerns draft support in the Workflow transition rules APIs. It does not remove the separate workflow scheme draft functionality.

Workflow schemes map issue types to workflows. When an active workflow scheme is edited, Jira can create a draft copy. Administrators can modify that copy and publish it to replace the active scheme.

The workflow scheme draft endpoints remain available, including operations such as:

POST /rest/api/3/workflowscheme/{id}/createdraft
GET  /rest/api/3/workflowscheme/{id}/draft
PUT  /rest/api/3/workflowscheme/{id}/draft
POST /rest/api/3/workflowscheme/{id}/draft/publish

These endpoints manage workflow scheme drafts, not the draft filtering and identification that was removed from the Workflow Rules APIs.

If an integration manages workflow scheme mappings, its existing scheme-draft logic should not be removed merely because it contains the word draft. Review the API group and its purpose before changing anything.

What About Deleting Workflow Rules?

The delete operation also needs a code review:

PUT /rest/api/3/workflow/rule/config/delete

Its request body identifies the workflow and the rule IDs to delete. The draft property must be removed from the workflowId object here as well.

There is an additional permission distinction: Atlassian documents this delete operation as available to Connect apps, while Forge and OAuth 2.0 apps cannot access this REST resource.

An integration should not assume that removing the draft property makes the delete operation available to every app type. Check the app's platform and permissions separately.

Test the Migration Without Changing Production Workflows

A useful test should cover more than whether the request stops returning HTTP 400.

First, run the updated retrieval request and confirm that the application can read the expected rule configurations. Then test an update using a rule owned by the app. Check the response at the individual rule level and confirm that the intended configuration was changed.

For a safer rollout, include these checks:

Search the codebase for remaining draft query parameters and WorkflowId.draft properties.
Confirm that retrieval requests use supported filters.
Verify that update payloads contain workflow names without the removed property.
Check pagination when processing multiple workflows.
Inspect per-workflow and per-rule errors in update responses.
Confirm that the app has the required permissions and API scopes.
Test the integration against a non-production Jira site before deploying it to production.

If the integration also manages workflow schemes, test those operations separately. They belong to a different API group and have their own behavior.

Common Problems During the Update

Problem	Likely reason	What to check
HTTP 400 during retrieval	The request still contains `draft`	Inspect the query string and shared request builders
HTTP 400 during an update	The payload still includes `workflowId.draft`	Check serialized JSON, not just the TypeScript model
HTTP 403	The app lacks the required permission or scope	Review Jira permissions and app authorization
Some rules are not updated	Individual rule or workflow errors were returned	Inspect `updateResults` and its error fields
Only some workflows are processed	The application reads only the first page	Implement pagination
Delete operation is unavailable	The app type is not supported for that operation	Check the documented Connect-only restriction

Keeping Jira Integrations Maintainable

The removal is a good reason to separate workflow identification from workflow rule configuration in the application.

A shared workflow model should represent only the fields supported by the API. Request builders should also be specific to the API operation they serve instead of attaching optional properties to every workflow request.

For example, an internal application may still track whether a workflow is considered a draft for its own administrative interface. That information should remain separate from the object sent to Jira's Workflow Rules APIs.

This separation makes future API changes easier to handle. When Atlassian changes an endpoint contract, developers can update the integration layer without rewriting unrelated application logic.

Conclusion

The November 2, 2026 change requires Jira Cloud integrations to stop using draft-state filtering and identification in the Workflow transition rules APIs. Remove the draft query parameter, remove WorkflowId.draft from request models and payloads, and verify how the application retrieves and updates rule configurations.

Do not remove workflow scheme draft functionality as part of the same migration. Those endpoints serve a different purpose and remain available.

The safest update is a focused API-contract change followed by tests for retrieval, updates, pagination, permissions, and individual rule errors. That keeps the integration aligned with the current Jira Cloud API without disrupting unrelated workflow administration features.