# Epic AUTOWORK-209 - Workflow transition rules Project: Stream Workflows & Automations Status: in specification URL: https://community.openproject.org/work_packages/AUTOWORK-209 ## Detailed specification ### Motivation and background information **This epic answers one question for every status change: May this status change happen, and what is needed first?** Teams moving from Jira to OpenProject rely heavily on transition rules. Every status change answers two questions: who may make it, and what must be true before it happens. Conditions and validators are among the most used workflow features in large Jira instances. Without them, these rules would get lost in a migration. Users would then have to remember the rules themselves, and data quality would drop. Today OpenProject can only restrict status changes per role, through the workflow matrix. It cannot ask for missing information, check field values or block a status change based on rules.
**Jira features covered by this epic (e.g. conditions and validators)**

Jira feature	What it does in Jira	Use case
Conditions: Project Role, Group, Permission	Only users with a certain role, group or permission can make the transition	UC1
Conditions: Only Assignee, Only Reporter, User in Custom Field	Only the assignee, the reporter or a user named in a field (e.g. Approver) can make the transition	UC1
Validators: Fields Required	Blocks the transition if certain fields are missing	UC2
Transition screens	Show the user a form during the status change to fill in missing information	UC2
Condition: Value Field, scripted conditions and validators	Allow the transition only if field values meet a rule (fixed value, other field, pattern, date, linked or child issues)	UC3
Workflow schemes per project	Different rules per project and issue type	UC4
Validators: Comment Required	Blocks the transition if a comment is missing	UC5
Condition: Hide transition from user	Transition only the system or API can make	UC6

**Use Cases** **Use Case 1 Restrict who can change a status** **Only defined users can move a work package from one status to another**, based on their role, group, permission, or their relation to the work package (assignee, author, or a user named in a field such as "Approver") Example: If a user without the role "Developer" opens a work package in status "On Hold" the status change to "In Progress" will not be available to this user. **Use Case 2 Mandatory information (within any field) when transitioning to/from certain status:** Ensures users **provide the necessary information in a certain field before a work package can move into a status**. This works for standard and custom fields. Example (**when entering a status**): If a user sets a work package to Done while a field Version is empty, or sets a work package of type Bug to Cancelled without a comment the user is asked for the information required for the target status, e.g. "Set a target version to move this work package to Done" or "Add a reason why this work package is cancelled." Example (**when leaving a status**): If a work package leaves “In review” and “Reviewer” is empty, the user is asked to "Select a reviewer before continuing". After user adds a reviewer -> status -> target status **Use Case 3 Allow a status change only if rules are met** **Status change is blocked when field values do not meet defined rules**. Several rules can apply to the same status change. A rule can: * compare a field with a fixed value or with another field * check if a text follows a pattern, e.g. an ID like "ABC-1234" * check related work packages, e.g. whether all children are closed Example: If a user sets a work package to Done while no target version is set, or while a Planned Availability Date lies in the past, or the child work package is still open the user would see a dialogue "This work package cannot be set to Done: a target version must be set" or " The planned availability date must be today or later" and/or "This work package cannot be set to Done: all child work packages must be closed" **Use Case 4 Project-specific rules:** Admins can set **different rules per project and work package type**. Example: If a project ALPHA requires a field to be updated on the status cancelled and project BETA does not, only users in project ALPHA are asked to fill out the field. In the automations UI, you can define a scope of project(s) that the automation applies to. For ALPHA and BETA, this would imply two separate automation objects. Note: This is more a configuration. This applies to all other use cases.
\--- **Use cases out of scope for Q1 delivery**
**Use Case 5 Mandatory information (as a comment) when transitioning to/from certain status:** Ensures users **provide the necessary comment** before a work package can move into a status. Example (when entering a status): If a user sets a work package of type Bug to Cancelled without a comment the user is asked to "Add a reason why this work package is cancelled." Example (when leaving a status): If a work package leaves status “rejected” (e.g. reopening a work package), the user is asked to enter a comment. After user adds a comment -> status transition -> target status Example 2: When closing a task, require a comment. (Workaround: define a field similar to resolution that then is required as part of the transition). **Use Case 6 Status changes only the system can make** Admins can set up a status change that users cannot see or select. Only automation rules or the API can make this status change. Example: When all child work packages are closed, an automation rule moves the parent from In progress to Ready for release. Users cannot select Ready for release themselves.
### Acceptance criteria * Admins can define rules per status change and work package type * Several rules can apply to one status change -> all of them must be met * When a rule blocks a status change, the user sees which rule is not met and what to do * When information is missing, the user can add it directly during the status change * Rules apply wherever a status can be changed: work package view, tables, boards, bulk edit and API * Rules cannot be bypassed via the API ### Out of scope Anything the system does automatically after a status change, e.g. setting or clearing fields, creating work packages, updating related work packages or sending notifications: see \#\#AUTOWORK-200 | Attribute | Value | | --- | --- | | Mockups | | ## Planning | Attribute | Value | | --- | --- | | Roadmap | 2027 Q1 | | Date | | | Votes | | | List | RM Jira exit, RM Jira admin, TIB 2026 | | Target versions | | | Sprint | | | Backlog bucket | | | Relevance | Showstopper — Go-Live Blocker | ## Subitems _No work packages_ ## Bugs and other work packages _No work packages_ ## Details | Attribute | Value | | --- | --- | | Module | Administration / Type/Variants and Workflows | | Enterprise plan | | | Labels | | ## People | Attribute | Value | | --- | --- | | Assignee | Sonita Soth | | Accountable | Rosanna Sibora | | Product manager | Sonita Soth | | Designer | Parimal Satyal | | Developers | OP Dev Sirius Team, Mir Bhatia, David Friquet | | Requested by | | | Interest by | Express (8754), Black (37919), Bowling (40324), Home (224196000003952096), Periscope (224196000002193032) | ## Estimates and progress | Attribute | Value | | --- | --- | | Work | 160d 0h · Σ 500d 0h | ## Description **Summary:** Admins can define **rules for each status change**: **who** may make it, what information is **required** and which **conditions** must be met. The system enforces these rules for all users.