Moving from a Connect-only workflow app to Rule Kit
Atlassian ends support for Connect apps on 31 January 2027. If your Jira workflows use Workflow Rules (Typezoo), Custom Workflow Condition & Validator with Jira Expressions (Softgrown) or Cloud Workflows (Polymetis Apps), this page shows which of their rulesRule Kit for Jira Workflows can take over, which ones Jira already has built in, and which ones Rule Kit does not cover yet.
Updated .
Why now
- After 31 January 2027, installed Connect apps keep running, but Atlassian only fixes critical security problems in them and expects breakages to grow (Getting ready for Connect end of support, atlassian.com).
- An app that only has a Connect descriptor cannot publish updates any more, so these three apps cannot ship a fix for a new Jira change.
- Atlassian Administration already marks Connect apps that have no migration plan with a warning (What admins see, developer.atlassian.com). On 27 October 2026 we found no announced Forge plan for any of the three apps.
What carries over
Nothing is imported automatically. Atlassian's migration path only carries settings when a vendor moves its own app to Forge; rules from another vendor's app are set up again (Migrate Jira workflow extensions, developer.atlassian.com). Rules written as Jira expressions cannot be pasted into Rule Kit either: Rule Kit rules are forms and JQL.
Before you start, open each workflow in the workflow editor, go through its transitions and note every rule, the app it comes from and what it checks or does. The tables below show where each kind of rule goes.
Workflow Rules (Typezoo)
| Their rule | Where it goes | How |
|---|---|---|
| Field values: type, status, priority, estimate, due date, custom fields | Rule Kit | JQL validator, for example issuetype != Bug, duedate < "2026-12-01", cf[10010] is not EMPTY |
| Summary starts with, description contains | Partly | JQL text search matches words, not prefixes or exact text: summary ~ "release" |
| Parent exists, parent is of a type | Rule Kit | JQL parent is not EMPTY; Parent/child validator on the parent with the filter issuetype = Epic |
| All or any sub-tasks in a status | Rule Kit | Parent/child validator on the children: all of them, or at least one, in a status category |
| Linked issues of a link type: all, any or none in a status | Rule Kit | Linked work items validator: link type, all / at least one / none, status category, optional JQL filter |
| Assignee is set, creator is a person | Rule Kit | JQL assignee is not EMPTY, creator = <account ID> |
| The person making the transition is a given user | Built into Jira, partly | Jira's User Is In Group or User Is In Project Role condition: a group or role, not one person |
| and, or, not | Rule Kit | Inside one JQL query; separate rules on a transition must all pass |
| Custom error message | Rule Kit | Every validator has a message field |
| A condition that hides the transition | Not yet | Rule Kit validators stop the transition with a message instead of hiding it |
| Add a comment | Not yet | — |
| Set the summary or description | Rule Kit | Run actions in order: set, append or prepend text |
| Set priority or resolution, assign | Built into Jira | Jira's Update a work item field and Assign post functions |
| if / then / else | Partly | Two rules with preconditions, one with X and one with NOT (X) |
Custom Workflow Condition & Validator with Jira Expressions (Softgrown)
Each of its documented examples works as a condition or a validator. Rule Kit has no condition, so where Rule Kit takes a row, it does so as a validator.
| Their example | Where it goes | How |
|---|---|---|
| The assignee is the person making the transition | Built into Jira | Jira's Only Assignee condition |
| Status, work type or priority is a value | Rule Kit | JQL validator: status = "In Progress", issuetype = Bug, priority = High |
| A due date is set | Rule Kit or built into Jira | JQL validator duedate is not EMPTY, or Jira's Field Required validator |
| The person making the transition is in a group | Built into Jira | Jira's User Is In Group condition |
| The person has a global permission | Partly | Jira's Permission condition checks project permissions, not global ones |
| The work item has at least one sub-task | Rule Kit | Parent/child validator on the children, at least one |
| The person making the transition is the project lead | Not yet | Nearest: Jira's User Is In Project Role condition with the Administrators role |
| The person has a service project role | Built into Jira | Jira's User Is In Project Role condition |
| A post function in your own code | Not yet | Rule Kit does not run custom code |
Cloud Workflows (Polymetis Apps)
| Their recipe | Where it goes | How |
|---|---|---|
| Close only when the sub-tasks are closed | Rule Kit or built into Jira | Parent/child validator on the children, all of them Done; or Jira's Sub-Task Blocking condition |
| The work item is in the active sprint | Rule Kit | JQL validator sprint in openSprints() |
| A bug needs an explanation comment from the person resolving it | Not yet | JQL cannot check a comment's length or author |
| A spec and a test plan are linked and past New | Rule Kit | Two linked work items validators, at least one each, filters issuetype = Spec AND status != New and issuetype = "Test Plan" AND status != New |
| A price total on the sub-tasks is under a limit, or the person is the approver | Not yet | Rule Kit has no sums and no checks on the person making the transition |
| Expression tester | Partly | Rule Kit checks your JQL with Jira when you save the rule; there is no separate tester |
Common rules, rebuilt
Each of these was tried on a Jira Cloud test site before we listed it here.
- No progress while a blocker is open
- Linked work items validator: link type “is blocked by”, None of them, required status To Do and In Progress.
- Close an epic only when its work is done
- Parent/child validator on the children: All of them, required status Done, precondition
issuetype = Epic. - Children only under an epic
- Parent/child validator on the parent: must be in the required status, all three status categories, filter
issuetype = Epic. - Bugs need a due date before work starts
- JQL validator: must match
duedate is not EMPTY, preconditionissuetype = Bug. Other work types are let through. - A linked bug is required
- Linked work items validator: the link types you use, At least one, all three status categories, filter
issuetype = Bug. - Someone is assigned before Done
- JQL validator: must match
assignee is not EMPTY, preconditionissuetype in (Story, Bug).
Differences to know
- Validators, not conditions. The transition stays visible and stops with your message when the rule fails.
- The work item, not the person. Rule Kit checks the work item. Rules about the person making the transition go to Jira's built-in conditions.
- Status categories. The linked work items and parent/child validators check To Do, In Progress and Done. For a particular status, add a filter such as
status = "QA". - The saved work item. Values typed on the transition screen are not visible to the JQL.
- Company-managed projects only. Team-managed projects are not supported.
- Forge workflow rules are in Preview. Atlassian labels the Forge workflow modules that Rule Kit uses as Preview.
The full list of rules and limits is on the Rule Kit for Jira Workflows page.
Price and support
Free for sites with up to 10 users. Above that, $0.60 per user a month for the first 100 users, with a lower price per user above 100.
Questions about moving a rule: write to muhammedsaidcakir@msclabs.trwith the rule and the app it comes from. Monday to Friday, 09:00–18:00 Istanbul time (UTC+3); we aim to reply within 48 hours on working days.