**As** an OpenProject admin 
**I want to** set up automated workflows
**so that** project members are relieved of tedious work and work packages status and values are more conform.

Begin of the insertion**Acceptance criteria**End of the insertion Begin of the deletion ## Customer use casesEnd of the deletion

* Begin of the insertionAll changes caused by automations are performed by a new system user that gets introducedEnd of the insertion Begin of the deletion If I set the statusEnd of the deletion to Begin of the insertionOP.
* The new system user's action are limited toEnd of the insertion Begin of the deletion "in progress",End of the deletion the Begin of the insertiongiven permissions.
* When certain actions can notEnd of the insertion Begin of the deletion progress shouldEnd of the deletion be Begin of the insertionperformed, due to lack of permissions, admins need to be notified about it.End of the insertion Begin of the deletion increased by 10%End of the deletion
* Begin of the insertionAll changes to WPs need to create a new journal entry. The the new system user is shownEnd of the insertion Begin of the deletion Enter project progressEnd of the deletion in Begin of the insertionthe journal entry as performing user of this changes.

**Why?**

_"Automate the routine and unlock potential"_

Automated workflows streamline operations and improve overall productivity by

* Relieving team members of tedious administrative tasks and allowing themEnd of the insertion Begin of the deletion % --> automatic status changeEnd of the deletion to Begin of the insertionfocus on more valuable work.End of the insertion Begin of the deletion "in progress"End of the deletion
* Begin of the insertionReducing the likelihood of human error.
* Allowing for controlled changes in project areas for which team members would otherwise not have permissions for.

The team ends up with increased efficiency, productivity and consistency.

## Customer use cases

* End of the insertion Close Milestones automatically through a work package relation (e.g. includes/part of or precedes/follows) when predecessor has been closed
* If all the Tasks have been set to "Closed" -> Then the overlying Parent (for example, a Project under which all those tasks are arranged) is automatically set to "Closed" as well.
* Someone creates a task; status is new  -> Someone different from the author adds a comment  -> Status should now automatically change from new to "in progress"
* If a work package is between start and finish date AND there are preceding or blocking WPs that are not closed yet, set status to "blocked"
* If status change is to "closed" and there is a following WP, email or notify assignee of following work package
* I would say that the status would only toggle automatically when the Assignee does something (comment \*\*or\*\* enters "spent time").
* 'solved' status, then the assignee was automatically removed, as the CCB needed to assign a different user.
* For changing user defined values like a checkbox in the task overview by changing the task status.
* Would be helpful to set the progress to 100% once a WP is moved to "Closed" Begin of the insertion
* Enter project progress in % --> automatic status change to "in progress"End of the insertion

## Customer cases (unified and grouped)

### Triggered by user changes in WP

#### Status changed -> change field to value

* Status Begin of the deletion is changed to "in progress" -> progress gets changed to 10%
* Status is closed -> progress gets changed to 100%
* StatusEnd of the deletion set to solved -> assignee gets removed
* Status is changed -> custom field checkbox gets changed Begin of the insertion
* Status is closed -> progress gets changed to 100%End of the insertion

#### Field is changed -> change status

* Spent time is added -> status gets changed to in progress
* When progress is changed to > 0% -> status gets changed to "in progress"

#### Others

* Comment is added -> status gets changed

### Triggered by user changes in relational WP

#### Status is changed -> trigger from relational -> change status if all/some/one relational has status

* Status is changed to close -> relational milestone status gets changed to close
* Status is changed -> parent status gets changed

#### Status is changed -> trigger from relational -> action

* Status is closed -> users of following WP get notified
* Status is open -> preceding gets blocked (out of scope)UI

###

## Additional functionality needed to move from "Custom actions" to **Automation**

### Triggers (sorted by priority)

* Button \[label\] (exist but needs a label input)
* Other automation
* Status transition to \[status\]

Out of scope:

* Field(s) updated \[field\] \[change\] (user needs to specify field and what changes happened e.g. all, specific value, deleted etc)
* Created
* Deleted
* Comment \[added/edited/deleted\]
* Assigned
* Linked

### Condition

* Status of all \[relation\] is \[status\]

### Action

* Trigger \[automation\] for \[relation\]

## Use cases example implementation FACHKONZEPT

###

### AUFTRAG is closed

```text
Trigger: Status transition to "closed"

Condition
- Type: "AUFTRAG"

Action 
- Trigger automation: "Close KONZEPT when done" for "including" work packages
```

### Close KONZEPT when done

```text
Trigger: Other automation

Conditions 
- Type: "FACHKONZEPT" or "DV-KONZEPT"
- Status of all relations: "including" is "closed"

Action
- "Close"
```

## Wireframes

### New UI options needed

<img class="op-uc-image op-uc-image_inline" style="width:594px;" src="/api/v3/attachments/92765/content">

###

### Automation: AUFTRAG is closed

<img class="op-uc-image op-uc-image_inline" style="width:660px;" src="/api/v3/attachments/92764/content">

### Automation: Close KONZEPT when done

<img class="op-uc-image op-uc-image_inline" style="width:753px;" src="/api/v3/attachments/92763/content">

### Begin of the deletion Purge (outdated)

**Acceptance criteria**

* Custom actions triggered by status change (by user, in a board etc).
* Trigger types:
* Trigger for one WP
* created (Event in after\_perform of WP Create service)
* updated (Event in after\_perform of WP Update service)
* status, assignee...
* relations
* file links
* attachments
* watchers
* deleted (Event in after\_perform of WP Delete service)
* &quot;remotely called&quot; (some code explicitly releases a trigger e.g. another automation rule)
* pass a original event identifier
* &quot;on relation&quot;???
* Out of scope: Trigger for general app events, such as &quot;User was added, invited, blocked&quot;
* Rule 1 (on AUFTRAG)
* Trigger: status change
* Condition: Type is AUFTRAG
* Action:
* Release automation trigger (&quot;remotely called&quot;) for all WPs that have a &quot;includes&quot; relation with the current WP.
* Rule 2 (on FACHKONZEPT)
* Trigger: &quot;remotely called&quot;
* Condition:
* Type is FACHKONZEPT
* All related work packages with relation type &quot;includes&quot; have status &quot;closed&quot;
* Action: Set status to &quot;closed&quot;

<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/92651/content"> <img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/92653/content"> <img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/92652/content">End of the deletion