# Epic AUTOWORK-200 - Automation rules Project: Stream Workflows & Automations Status: specified URL: https://community.openproject.org/work_packages/AUTOWORK-200 ## Detailed specification ### Motivation and background information **This epic answers one question: When something happens, what should the system do automatically?** Teams spend a lot of time on routine work like assigning new work packages, setting fields after a status change, creating follow-up tasks, reminding people of stale work. Done by hand, these steps take time are easy to forget and done differently by different people. Teams moving from Jira rely on two features for this: post-functions on workflow transitions and Jira Automation. Without an equivalent in OpenProject, these automations would get lost in a migration and teams would have to do this work by hand again. Automation rules: - take routine admin work off the team, so they can focus on more valuable work - reduce human error - allow controlled changes in areas where team members don’t have permission themselves This epic now includes \#\#AUTOWORK-241 **Jira features covered by this epic (e.g. post-functions and automations)**

Jira feature	What it does in Jira	Use case
Post-functions: Update Issue Field, Clear Field	Set or clear fields after a transition	UC1, UC15
Automation conditions: Issue fields, User, Advanced compare	Run actions only if field values or the user meet a condition	UC2
Post-function: Create Issue; Automation: Create issue, Create sub-tasks	Create new issues automatically	UC3, UC6
Post-functions on related issues: Update field, Comment on linked issues	Update or comment on parent, children or linked issues	UC4
Post-functions: Copy field value from parent, Copy issue fields	Copy values between related issues	UC5
Automation trigger: Field value changed; Automation action: Transition issue	Change status when a field or the assignee changes or a comment is added	UC7, UC12
Automation action: Edit issue, Add label	Set labels or field values	UC8
Automation action: Assign issue; Post-function: Assign to current user	Set the assignee automatically	UC9
Automation trigger: Scheduled	Run rules daily, hourly or at a fixed rate on a set of issues	UC10, UC14, UC16
Automation action: Comment with restricted visibility	Add comments only certain roles or groups can see	UC11
Automation action: Send email, Send notification	Inform defined people	UC13

**Use Cases** **Use Case 1 Set/update or clear fields on a status change** **Fields are updated** automatically when a work package moves to a status. Example: If a work package of type Bug moves to Rejected, the field Version is set to empty. ### **Use Case 2 Run a rule only if conditions are met** An automation rule only runs its actions **when defined conditions are true**. A condition can **compare a field with a fixed value** or with another **field**, check if a **text follows a pattern**, or check whether the **user** who triggered the rule is in a **certain group or role**. Example: If a work package of type Change Request moves to Approved and the user who approved it is in the group Change Board, a child work package Implement {subject} is created. If someone outside the Change Board approves it, nothing happens. ### **Use Case 3 Create work packages on a status change** New **work packages are created** automatically when a work package reaches a status. Example: If a work package FEATURE moves to In Testing, create a new and related WP TEST with name Test task {subject} and comment on the Work Package FEATURE “Test task created automatically” Out of scope: Mandatory fields upon creation of the work package, creating work packages in other projects or confidential work spaces. **Use Case 4 Change status automatically when a field gets a certain value** Example: If field Risk category is set to Mitigated, status changes to In progress. Comment will be added "status changes based on the risk category: mitigated". Trigger: Field updated e.g. version updated
**Use case 5 Set labels or field values automatically** Labels or field values are set automatically when a work package is created or changed. Example: If a work package of type Bug is created with priority High add Label to "urgent" ### **Use Case 6 Select assignee automatically** The assignee is set automatically based on rules. It can be a **fixed** user or group, a user in a group or role, the user **who triggered** the rule, a **user named** in a field (e.g. Reviewer), or the **assignee of the parent**, the **epic** or another **work package**. This assignment is singular and pre-defined in the UI. Example: If a work package of type Bug is created and the assignee is empty, the QA team is assigned and the comment "Assignee was automatically selected based on the work package type BUG" is added. If a user moves a work package to In progress and the assignee is empty, this user moving it becomes the assignee.
**Use case 7 Run rules on a schedule** Rules run at a fixed **time** (e.g. daily, weekly) or at a fixed **rate** (every X days, hours or minutes). They **run on all work packages of a saved filter**, either for each work package on its own or once for all of them together. Concrete scheduling rules to be discussed. This is more valuable daily or weekly, but we can start with daily as the minimum. Example 1: Every day at 08:00, work packages without an update for 5 days get the comment "@Assignee, this work package has not been updated for 5 days. Please add a status update. cc @Author, @Responsible". Example 2: Every ~~four hours~~ 24 hours, all open bugs without an assignee are collected and the team lead gets one email listing all of them. ### **Use case 8 Automated comments with restricted visibility** When a rule adds a comment, the admin can effectively limit who can see it, e.g. only members of a certain role or group. This comment is created as an internal comment. Example: If a work package is closed automatically after a reviewer confirmed the fix, the rule adds the comment "Closed automatically after reviewer confirmed the fix", visible only to the role QA team. ### **Use case 9 Close work packages automatically when specific variable changes (assignee, specific comment added)** A work package is closed automatically when a defined change happens, e.g. a new assignee or a specific comment Example: If a reviewer adds comment like Confirmed Fixed, add a comment "this work package was closed automatically after reviewer confirmed the fix". Status changes to Closed. \--- **Use cases out of scope for Q1 delivery**
**Use Case 10 Copy field values from related work packages (critical, delivery planned for early Q2)** When a work package changes status, a **field value is copied from a child to its parent**, or **from a linked work package to this one**. Example: If a child work package of type Test moves to Done, its field Test result is copied to the parent Feature. *Note: We can see if we can make this more specific/smaller. This might make it easier for us to deliver this earlier (critical, not show stopper).*
### **Use Case 11 Create tasks or sub-tasks automatically (critical, delivery planned for early Q2)** New work packages are created automatically when a **work package is created or changed** Example: If a work package of type Feature is created add a comment "Sub-tasks were created automatically". New child work packages are created, e.g. Design WP, Implementation WP, Test WP *Note: This is somewhat related to Use case 10, where new tasks would be able to get some existing values too. Also critical, not show stopper.*
**Use Case 12 Inform defined people (Sending feedback)** Defined people (like watcher, accountable or assignee) are informed automatically when something happens to a work package. Example: If a work package is closed, send a notification to defined people by email
**Use Case 13 Update related work packages on a status change** A status change **updates or informs related work packages: the parent, the children, linked work packages**. The rule can **add a comment, set a field or clear a field**. Example 1: If an epic moves to "Ready for development", comment on every child work package: "The linked work package ID is Ready for development. You can start working on this." Example 2: If an epic moves to Cancelled, the field Target version is cleared on all its children.

Table for Automation Rules

Ranked by priority	Use case	Trigger	Condition	Action	Design Notes
1	Set/update or clear fields on a status change	Bug moves to Rejected, or back to In progress	Type Bug	Resolution = "Won’t fix" or Resolution cleared
2	Run a rule only if conditions are met	Change Request moves to Approved	User who approved is in group Change Board	Create a child WP Implement {subject}, comment on FEATURE "Implement created automatically"
3	Create work packages on a status change	FEATURE moves to status In Testing	Status change from In Progress to In Testing	Create a related WP TEST "Test task {subject}" comment on FEATURE "Test task created automatically"
4	Change status when a field gets a value	Field updated, e.g. version updated	Field Risk category= Mitigated	Comment "Status changed automatically because the risk category is now Mitigated" and status = In progress
5	Set labels or field values automatically	Work package is created or changed	Type Bug with priority High	Add label urgent
6	Select assignee automatically	Work package is created, or moves to In progress	Assignee is empty	Assignee = QA team and comment "Assignee was automatically selected based on the work package type BUG" or assign the user who moved it
7	Run rules on a schedule	Schedule: every day at 08:00 or every 4 hours	No update for 5 days, or open bugs without assignee	Comment "@Assignee, this work package has not been updated for 5 days. Please add a status update. cc @Author, @Responsible"or one email listing all open bugs to the team lead
8	Automated comments with restricted visibility	Any rule that adds a comment	Visibility set by admin, e.g. role QA team	Comment visible only to the chosen role or group
9	Close automatically when a variable changes	New assignee or specific comment added	Reviewer adds comment like "Confirmed Fixed"	Comment "This work package was closed automatically after reviewer confirmed the fix" and status = Closed
12	Inform defined people (Sending feedback)	Something happens to a work package, e.g. it is closed	Defined people exist (watcher, accountable, assignee)	Send Done notification via email
13	Update related work packages on a status change	Epic moves to Done or Cancelled	Related work packages exist (parent, children, linked, or found by a saved filter)	Done: comment on every linked WP: "The linked {ID} work package is done. You can start working on this" Cancelled: clear Target version on all children
10	Copy field values from related work packages	Child of type Test moves to Done	Has a parent	Copy Test result to the parent
11	Create tasks or sub-tasks automatically	Work package is created or changed	Type Feature is created	Comment "Sub-tasks were created automatically" and create child/related WPs, e.g. Design WP, Implementation WP, Test WP

### Acceptance criteria * A rule consists of a trigger, optional conditions and one or more actions * Triggers: status change, work package created, updated or deleted, field changed, comment added, attachment added, schedule * Actions: set or clear fields (including status, priority and assignee), add labels, add comments, create work packages, update or copy fields in related work packages, notify defined people * Only admins can create and change automation rules * Admins can limit a rule to certain projects and work package types * All changes made by rules are done by a system user and are visible in the work package history * Rules can only perform non-destructive actions (no deleting, no sharing) * Rules cannot trigger each other in an endless loop * Admins can pause single rules or all rules * Rules never block a user's action ### Out of scope | Attribute | Value | | --- | --- | | Mockups | | ## Planning | Attribute | Value | | --- | --- | | Roadmap | 2027 Q1 | | Date | | | Votes | 31 | | List | RM Jira exit | | Target versions | | | Sprint | | | Backlog bucket | | | Relevance | Showstopper — Go-Live Blocker | ## Subitems | ID | Type | Subject | Status | Assignee | Target versions | Project | Priority | Spent time | | --- | --- | --- | --- | --- | --- | --- | --- | --- | | AUTOWORK-205 | Feature | Rename Custom Actions to Automations without additional functionality | tested | | 18.0.0 | Stream Workflows & Automations | Medium | | | AUTOWORK-201 | Feature | Basic Administration for Automations | new | Sonita Soth | Product Backlog | Stream Workflows & Automations | Medium | | | AUTOWORK-203 | Feature | Basic UI structure for automation rules (Trigger, Conditions, Actions) | new | | Product Backlog | Stream Workflows & Automations | Medium | | | AUTOWORK-202 | Open Point | What are the relevant automation triggers? | needs clarification | | | Stream Workflows & Automations | Medium | | | AUTOWORK-204 | Open Point | What are the relevant automation actions? | needs clarification | | | Stream Workflows & Automations | Medium | | | AUTOWORK-207 | Feature | Pause some or all automation rules | new | | | Stream Workflows & Automations | Medium | | | AUTOWORK-208 | Feature | Time based automation triggers | new | | | Stream Workflows & Automations | Medium | | ## Bugs and other work packages | ID | Type | Subject | Status | Assignee | Target versions | Module | | --- | --- | --- | --- | --- | --- | --- | | AUTOWORK-206 | Code maintenance | Turn automation actions into an actual associated table | closed | | 18.0.0 | | | AUTOWORK-264 | User Story | Configurable email notification on status change | needs clarification | | | | | AUTOWORK-204 | Open Point | What are the relevant automation actions? | needs clarification | | | | | AUTOWORK-202 | Open Point | What are the relevant automation triggers? | needs clarification | | | | ## Details | Attribute | Value | | --- | --- | | Module | Administration / Type/Variants and Workflows | | Enterprise plan | | | Labels | | ## People | Attribute | Value | | --- | --- | | Assignee | OP Dev Sirius Team | | Accountable | Rosanna Sibora | | Product manager | Sonita Soth | | Designer | Parimal Satyal | | Developers | OP Dev Sirius Team, Mir Bhatia, David Friquet | | Requested by | | | Interest by | Black (37919), Joules (39703), Home (224196000003952096), Periscope (224196000002193032) | ## Estimates and progress | Attribute | Value | | --- | --- | | Work | 40d 0h · Σ 200d 0h | ## Description **Summary** Admins can define automation rules: when **something happens** to a work package, or **at a set time**, and **defined conditions are met**, the **system acts automatically**. It can set fields, create work packages, assign people, change statuses or add comments.