Clear Transitions for Jira

Remove Clear Transitions rules from your workflows before uninstalling. Otherwise Jira blocks those transitions.

The rules live in your Jira workflows, not in the app. You remove them in the Jira workflow editor. If the app is uninstalled while a rule is still on a transition, Jira blocks that transition. The admin page has a tab called Before you uninstall that lists every transition that uses a rule. Usage is recorded when a rule is saved or opened in the workflow editor, so the list may miss rules added before this version and may include rules whose workflow change was discarded.

After a reinstall. Rules already on transitions keep working in Jira. To restore them to the rule library and the usage list, open each rule once in the workflow editor.

1. Install the app from the Atlassian Marketplace.
2. Open the Clear Transitions admin page (Jira administrators only) under Jira admin settings > Marketplace apps > Clear Transitions to see the rule library and a short checklist.
3. Open the Jira workflow editor, select a transition and add a rule from the app. Pick the right entry:
   • Clear Transitions rule under Validators: blocks the transition and shows the message. This is the one I recommend, because users see why.
   • Clear Transitions rule (logged) under Validators: the same, plus the anonymous block log (see "Block log").
   • Clear Transitions condition (hides transition) under Conditions: hides the transition until the checks pass, with no message. Its description says "Hides the transition until the configured checks pass. Nobody sees a message."
   The rule builder opens for each.
4. Pick a template, or describe the rule in plain words and select Draft with AI.
5. Test the rule on real work items, then select Add or Update in the editor.
6. Select Update workflow at the top right of the workflow editor. The rule does nothing until the workflow is updated.

I can't add rules to your workflows for you. Adding a rule to a transition needs a Jira administration permission that the app doesn't ask for (the app has no admin scopes). A Jira administrator adds the rule in the workflow editor.

You can edit the message of every rule type except Custom expression. You can use these placeholders: {keys}, {status}, {n}, {field}, {sections}, {condition}. Other text in braces is not allowed.

Each example uses a transition into Done. Add the rule with Clear Transitions rule, test it, select Add or Update, and then Update workflow at the top right (without it the rule is not active). Then move a real work item.

Write what you want in plain words (up to 500 characters), for example "Story needs acceptance criteria in the description before review". The AI picks a rule type and fills in the form. It does not write the Jira expression: a fixed builder does that from the form. You see the rule as a form and as one plain sentence, and you must test it before you save.

The AI is Atlassian's built-in Forge LLMs service and runs inside Atlassian. It sees only your text and the names of fields, work types and link types. It never sees work item content. If the AI can't turn your text into a rule, pick a template instead. A draft that uses a custom expression is marked for extra review.

Type work item keys, or a search query (the first 50 work items are used). The Target status field is filled in from the transition; change it only if needed. Then select Test. You see which work items would be blocked and the message each would get: {n} of {total} work items would be blocked.

Under each result the test shows what the rule looked at: the child work items, every link in the words Jira shows on the work item (for example "is blocked by ABC-7 (In Progress)"), or how many comments you wrote in the last 10 minutes. You can also type keys in the search box.

A rule can't be saved until the test passes. If you change the rule or the status, test again. The app also runs the test again on the server when you save.

Limits of the test:

• The test checks work items as they are now. It can't simulate edits that users make on the transition screen.
• Comment required: in the test you count as the person moving the work item, so a comment you wrote in the last 10 minutes makes it pass.
• The test uses the status name you typed.

• After you save, the editor shows the rule as one sentence, for example "Blocks the transition until all child work items are done."
• The rule library (admin page) holds the main copy of each rule. The workflow holds a snapshot. If you change a rule in the library, the transitions that use the old version are shown as Outdatedon the admin page. The app can't update the workflow itself, so open each transition, edit the rule and save it again.
• Jira checks the rules each time a work item is moved through the transition.
• After an app update, rules already on transitions keep the checks they were saved with. Open each rule in the workflow editor, select Update, then Update workflow, to use the newest version.
• Each rule has a cost limit in Jira. The builder blocks rules that are too expensive to save.

Turn on Log blocks (anonymous) in the builder for a rule, and add the rule type Clear Transitions rule (logged)in the workflow editor. A normal rule is evaluated by Jira alone, so the app can't know when it blocks. The logged type lets the app see the block. It runs the rule as the app, inside Atlassian, and still stores no person.

• Only for child work item rules and linked work item rules.The builder enforces this on the logged type. Other rule types can't be logged, because the logged type checks the saved work item and can't see edits on the transition screen.
• The log keeps the work item key, the rule, the transition and the time. It never keeps an account ID or a name.
• It is kept for 90 days by default. On the admin page you can set 30 to 365 days. A daily job deletes older entries.
• The admin page shows blocks per rule (last 7 and 30 days), the latest 50 blocks, and the log as CSV text that you select and copy. The CSV has at most the newest 1000 blocks per rule.
• When you add the logged type in the workflow editor, the builder offers only the two loggable rule types and always logs them. It does not let you save another rule type on the logged type, because that rule would never block. Use the normal rule type for those.
• If the logged rule fails for any reason, the transition is allowed instead of blocked, so an error in the app never stops your team.

Switching a rule between the normal and the logged type means replacing the rule in the workflow editor.

• Rules:every rule with a plain sentence, version, where it is used, "Outdated" and "Missing field" warnings, and delete (a rule that is still used in a workflow can't be deleted).
• Block log: counts and the latest blocks, with CSV.
• Import / export:export the library as JSON and import it on another site. Rules in the JSON are checked, and invalid ones are skipped. Exported rules don't move into workflows by themselves.
• Settings: how long the block log is kept.
• Before you uninstall: the transitions that use a rule.

The Rovo agent appears after the app is installed. If it was added by an update to an existing installation, a Jira administrator may need to reinstall the app for it to show up.

The Clear Transitionsagent answers "Why can't PROJ-123 move forward?" It checks the work item against the rules in use, as you, and explains which rule blocks it and what the message says. It checks moving forward in general, not one named status. If some rules can't be checked, it says so. It can list the rules. It can't change rules or move work items.

• Runs on Atlassian. No data leaves Atlassian.
• Three scopes: read work items, read user access (needed for the rule test), and app storage. No admin scopes.
• The app stores no account IDs. See the privacy policy at https://www.helkrypt.no/privacy/apps.

Email support@helkrypt.no.