Workflow Guard adds guided conditions and validators to company-managed Jira Cloud workflows. Choose a focused check, select the values to allow, review the summary, then save and publish the workflow. No expression writing is required.
Install and configure
After Marketplace approval, install the app on your Jira Cloud site and use a Jira administrator account to edit a company-managed workflow. Team-managed workflows, Jira Server/Data Center, post functions and custom scripts are outside this release.
Select a transition in Jira's workflow editor. Add Workflow Guard under Validate details for a validator or Restrict transition for a condition. Choose a guard, complete its form and use Jira's Add or Update button. Publish the workflow changes. Reopen the rule's Summary and Edit tabs to review its saved configuration.
A validator rejects a transition when the requirement fails. You can customize its message when blocked. A condition returns a Boolean result to Jira and hides the transition when false; it has no failure-message field. If several conditions or validators are present, Jira also applies the other rules and their configured groups.
Jira controls how validation errors appear. In live testing, a native transition screen showed the configured message, while the inline status widget could return to its previous status without displaying it. Configure an appropriate native transition screen when a visible explanation is important. The app does not create screens or change workflows automatically.
Linked Work Status
Select the link type and direction relative to the work item being transitioned. For a link “A blocks B,” outward from A selects B; inward from B selects A. Either direction includes both. Other link types are excluded.
Choose specific status IDs or status categories, then All, At least one, or None. All requires every matching linked work item visible to the transitioning user to be in an allowed status. At least one requires one match. None requires no matching linked work item to be in an allowed status. Require at least one matching link makes an empty set fail. Without that setting, empty sets pass All and None but fail At least one. The summary states the empty-set behavior.
Subtask Status
Check the work item's subtasks using status IDs or categories and the same All, At least one and None choices. Require at least one matching subtask makes an empty set fail. This guard checks subtasks only; it does not check every possible child work item type or filter subtasks by issue type.
Parent Status
Choose the parent's allowed status IDs or categories. Set whether a work item with no parent passes or is blocked. An existing parent's disallowed status fails regardless of the missing-parent choice.
Existing Attachment Count
Enter the minimum number of attachments, at least one. The rule counts files available when Jira evaluates the guard. It does not inspect their contents, names, types or size.
Existing files are available independently of a transition screen. In the tested native screen, a file uploaded on that screen counted when Update was retried and was persisted with the successful transition. Other screens may have different timing. Do not assume an upload counts before Jira makes it available at evaluation.
Fix Version State
Choose All unreleased, At least one unreleased, All released, At least one released, or All not archived. Require at least one Fix Version makes an empty list fail. With that option off, All passes an empty list and At least one fails it.
Unreleased and not archived are separate properties. An archived unreleased version matches the unreleased test. Use an additional All not archived guard if both requirements are needed. The app reads version state; it never releases or archives a version.
Sprint State
Jira Software is required. Current sprint is active and Current sprint is future check the singular current sprint Jira exposes. No current sprint passes when that value is absent, even if completed sprints remain in history.
Has a completed sprint in history requires at least one past completed sprint. It can pass alongside No current sprint, or while a new current sprint exists. Completion of the controlled test sprint removed it from the current-sprint value and retained it in the closed-sprint history; the UI deliberately distinguishes those meanings.
Due Date Guard
Require a due date, compare it on or before/after today, or compare it on or before/after the parent's due date. Comparisons include equality. For comparisons, explicitly choose whether a missing due date, required parent or parent due date passes or fails. Due date must exist always fails when absent.
Today is Jira's calendar date for the transitioning user, rather than the browser's timestamp. Dates are calendar dates; the app does not calculate business days, offsets, durations or time-of-day deadlines.
Relationship Count
Count links or subtasks and choose At least, At most or Exactly. Link counts use only links Jira makes visible to the transitioning user. Link counts can include every type or a selected stable link type, with inward, outward or either direction. Subtask counts have no link-type/direction filter. Zero is a valid threshold. A count does not check the related work's status.
Licenses and saved rules
An inactive license makes configuration read-only and prevents new/updated guards from being saved. Existing guards continue applying their configured business requirements; the generated expressions do not use commercial license state. Refresh the Jira workflow editor after a license or installation change to obtain fresh app context.
Upgrades preserve saved rule configuration. Review workflows when changing statuses, relationships or requirements. An unsupported configuration version is preserved and cannot be overwritten through this editor until supported by the app.
Troubleshooting and limitations
If a transition is hidden, review its conditions and rule groups. If blocked, review validators, the failure message and native required fields. The guard does not bypass other Jira rules. Ensure the workflow was published and is the workflow used by the work item's type and project.
Configuration metadata uses the current user's Jira permissions. Jira controls permission to publish workflow changes. In the controlled test, an ordinary user could open a direct workflow URL and prepare a local edit, but Jira rejected publishing it; the published configuration stayed unchanged.
Linked Work Status and link-based Relationship Count evaluate only links visible to the transitioning user. In live permission QA, a restricted dependency returned HTTP 404 to the test user and was omitted entirely from issue.links. The same source had one matching link for the owner and zero for the test user. The app cannot validate the status or count of links Jira omits.
When no matching links are visible, Require at least one matching link blocks. With that setting off, All and None pass the empty visible collection; At least one fails. If some links are visible, requiring at least one does not establish that other hidden dependencies meet the requirement. To enforce a requirement across every dependency, ensure all users who may transition the source can browse the dependencies that matter. Default error messages disclose no related work item names, keys or statuses.
The app has no external application service, app database, arbitrary scripts, background automation or third-party analytics. It does not retrieve attachment contents. Conditions and validators run as Jira expressions without an app API request at transition time. Jira expression limits still apply; live volume tests covered 30 links, 30 subtasks, 21 attachments and 10 Fix Versions.
Uninstall safely
- Identify every workflow transition using Workflow Guard conditions or validators.
- Remove those rules from all affected workflows.
- Publish the workflow changes and verify transitions.
- Uninstall the app only after the rules have been removed.
Leaving rules behind can block transitions. The live uninstall test blocked a transition that would otherwise pass and Jira reported the missing validator. Reinstallation restored the tested rule; removing rules before uninstalling remains the supported procedure.
Support
NexaForge Labs: hello@renewalhub.co.za. Include the guard's settings, summary, Jira error and app version when possible. Remove personal/customer details from screenshots and logs. Do not send passwords, API tokens or credentials.