# Automate a project with a trigger, conditions, and actions > How a custom automation runs the actions you set in one project when its trigger fires and its conditions match, from building one to reading the record of each run. Lesson 3 of 12 in Plane Business · 4:14 · [Watch the lesson](https://academy.plane.so/videos/custom-automations) ## Chapters - [0:00](https://academy.plane.so/videos/custom-automations?t=0) A rule for one project - [0:30](https://academy.plane.so/videos/custom-automations?t=30) Build an automation - [2:02](https://academy.plane.so/videos/custom-automations?t=122) Watch it run and read the record - [3:00](https://academy.plane.so/videos/custom-automations?t=180) Automations worth copying - [3:52](https://academy.plane.so/videos/custom-automations?t=232) Review your automations ## A rule for one project A custom automation in Plane is a rule for one project. When its trigger fires and its conditions match, Plane runs the actions you set. It makes the routine edits nobody should have to remember: triaging new bugs, adding assignees and labels, leaving a comment or link, and archiving. ## Build an automation On Business and higher, a project admin builds one. This one hands work to QA when it reaches review. 1. Open **Project settings**, then **Automations**, and choose **Create automation**. 2. Give it a name and a description. The builder opens with two sections, **Trigger** and **Action**. 3. Pick one of five triggers: **Work item created**, **Work item updated**, **State changed**, **Assignee changed**, or **Comment created**. A review handoff uses **State changed**. 4. Add conditions under **Provided**. They check state, type, label, assignees, priority, or creator, and all of them must match. Pick one value with **is**, or several with **is any of**. The handoff needs one condition: State is In review. 5. Add the actions. They run in the order you add them. **Change property** adds the QA engineer as an assignee, and **Add comment** asks for a test on staging. **Add link** attaches a URL, such as a runbook. **Archive work item** and **Delete work item** must come last, and an automation holds one of them at most. An automation acts only in its own project, and its triggers are events, not a schedule. Changes it makes don't set off other automations. It stays off until you choose **Enable**, which needs a trigger and at least one action. ## Watch it run and read the record Once it's enabled, the next work item moved to In review sets it off. Plane adds the QA engineer, then posts the comment. The work item's activity credits the change to **Automation Bot**. Every automation uses that name, so the activity doesn't say which one ran. The automation's own **Activity** does. It lists each run with its work item and time, and a run opens to show who set it off. **Show fails** starts on, so state changes that didn't match the condition appear as failed runs. Their actions never ran. You can edit an automation while it's enabled. The edit applies from the next run, and earlier runs stay listed with their changes in place. Choose **Disable** to stop it. You can delete an automation only after you disable it. ## Automations worth copying The handoff covers review. Two more handle new bugs and urgent work. - **New bugs:** when a work item is created, provided its type is Bug, set Priority to High and add the QA engineer. - **Urgent work:** with the same trigger, provided priority is Urgent, add the project lead, then a comment asking for an estimate today. Put **Archive work item** and **Delete work item** behind a condition. An automation archives in any state, so on **State changed** alone it would archive every work item that moves. The default automations on the same page, like **Auto-archive closed work items**, need no builder. You switch one on and pick a period. ## Review your automations One **Automations** page now holds all three, enabled: new bugs triaged, urgent work escalated, and work handed to QA at review. ## Try it Open Project settings, then Automations, choose Create automation, and give it a name and a description. ## Plans - Business: Custom automations ## Docs - [Custom automations](https://docs.plane.so/automations/custom-automations) - [Automations overview](https://docs.plane.so/automations/overview) ## Transcript ### A rule for one project A custom automation in Plane is a rule for one project. When its trigger fires and its conditions match, Plane runs the actions you set. It makes the routine edits nobody should have to remember: triaging new bugs, adding assignees and labels, leaving a comment or link, and archiving. You'll build one, watch it run on a work item, and read what it did. Let's take a closer look. ### Build an automation On Business and higher, a project admin opens Project settings, then Automations, and chooses Create automation. Give it a name and a description, and the builder opens with two sections, Trigger and Action. Pick one of five triggers: Work item created, Work item updated, State changed, Assignee changed, or Comment created. A review handoff uses State changed. Conditions go under Provided. They check state, type, label, assignees, priority, or creator, and all of them must match. Pick one value with is, or several with is any of. The handoff needs one condition: State is In review. Actions run in the order you add them. Change property adds the QA engineer as an assignee, and Add comment asks for a test on staging. Add link attaches a URL, such as a runbook. Archive work item and Delete work item must come last, and an automation holds one at most. An automation acts only in its own project, and its triggers are events, not a schedule. Changes it makes don't set off other automations. It stays off until you choose Enable, which needs a trigger and at least one action. ### Watch it run and read the record Once it's enabled, the next work item moved to In review sets it off. Plane adds the QA engineer, then posts the comment. The work item's activity credits the change to Automation Bot. Every automation uses that name, so the activity doesn't say which one ran. The automation's own Activity does. It lists each run with its work item and time, and a run opens to show who set it off. Show fails starts on, so state changes that didn't match the condition appear as failed runs. Their actions never ran. You can edit it while it's enabled. The edit applies from the next run, and earlier runs stay listed with their changes in place. Choose Disable to stop it. You can delete an automation only after you disable it. ### Automations worth copying The handoff covers review. Two more handle new bugs and urgent work. When a work item is created, provided its type is Bug, the first sets Priority to High and adds the QA engineer. The second uses the same trigger, provided priority is Urgent. It adds the project lead, then a comment asking for an estimate today. Put Archive work item and Delete work item behind a condition. An automation archives in any state, so on State changed alone it would archive every work item that moves. The default automations on the same page, like Auto-archive closed work items, need no builder. You switch one on and pick a period. ### Review your automations One Automations page now holds all three, enabled: new bugs triaged, urgent work escalated, and work handed to QA at review.