---
metadata:
  - name: generator
    content: Diplodoc Platform v5.47.3
alternate:
  - https://yandex.com.tr/support/tracker/en/dev-process-automation.md
---
> **Documentation Index:** Fetch the complete configuration index at https://yandex.com.tr/support/tracker/en/llms.txt

<!-- source: en/_assets/style/image.md -->

<!-- endsource: en/_assets/style/image.md -->

# Automating recurring actions

You can automate common actions related to Tracker issues using [triggers, auto actions, and macros](https://yandex.com.tr/support/tracker/en/automation.md). You can update issue parameters based on events, either periodically or on a command, as well as create new issues by schedule.

Let's look at some examples of how you can automate certain actions in Tracker:

## Picking assignees automatically {#auto-assign-executor}

If a certain issue falls under the responsibility of a specific employee, you can automatically make them an assignee for that issue using [triggers](https://yandex.com.tr/support/tracker/en/user/create-trigger.md). When the conditions are met, the trigger automatically updates the issue parameters.

For example, the tester should start testing a new product feature once the developer changes the issue status to **Ready for testing**. To automatically make a test engineer an issue assignee, set up the trigger as follows:

1. <!-- source: en/_includes/transition-page.md -->
   In the left-hand panel, click <svg xmlns="http://www.w3.org/2000/svg" width="18" height="18" fill="currentColor" aria-hidden="true" class="yc-icon nv-composite-bar__menu-icon" viewBox="0 0 16 16"><path fill-rule="evenodd" d="M6.702 3.013 8 3.5V2.386A2 2 0 0 1 10.702.513l3.351 1.257A3 3 0 0 1 16 4.579v4.035a2 2 0 0 1-2.702 1.873L12 10v1.114a2 2 0 0 1-2.702 1.873L8 12.5v1.114a2 2 0 0 1-2.702 1.873L1.947 14.23A3 3 0 0 1 0 11.421V7.386a2 2 0 0 1 2.702-1.873L4 6V4.886a2 2 0 0 1 2.702-1.873ZM5.5 6.563l.553.207A3 3 0 0 1 8 9.579v1.319l1.824.684a.5.5 0 0 0 .676-.468V7.079a1.5 1.5 0 0 0-.973-1.405L6.176 4.418a.5.5 0 0 0-.676.468v1.676Zm4.553-2.293L9.5 4.062V2.386a.5.5 0 0 1 .676-.468l3.35 1.256c.586.22.974.78.974 1.405v4.035a.5.5 0 0 1-.676.468L12 8.398V7.079a3 3 0 0 0-1.947-2.809ZM1.5 11.421V7.386a.5.5 0 0 1 .676-.468l3.35 1.257c.586.219.974.779.974 1.404v4.035a.5.5 0 0 1-.676.468l-3.35-1.257a1.5 1.5 0 0 1-.974-1.404Z" clip-rule="evenodd"/></svg> **Queues** and select a queue. {#queue}
   <!-- endsource: en/_includes/transition-page.md -->

1. <!-- source: en/_includes/transition-page.md -->
   In the top right corner of the queue page, click <svg xmlns="http://www.w3.org/2000/svg" width="20" height="20" fill="currentColor" aria-hidden="true" class="yc-icon nv-aside-header-footer-item__icon"><svg xmlns="http://www.w3.org/2000/svg" fill="none"><path fill="currentColor" fill-opacity=".85" fill-rule="evenodd" d="M8.875 2.125h2.25a.5.5 0 0 1 .5.5v.23c0 1.925 2.083 3.128 3.75 2.165l.2-.115a.5.5 0 0 1 .682.183l1.125 1.949a.5.5 0 0 1-.183.683l-.2.115c-1.666.962-1.666 3.368 0 4.33l.2.115a.5.5 0 0 1 .183.683l-1.125 1.949a.5.5 0 0 1-.683.183l-.199-.115c-1.667-.963-3.75.24-3.75 2.165v.23a.5.5 0 0 1-.5.5h-2.25a.5.5 0 0 1-.5-.5v-.23c0-1.925-2.083-3.128-3.75-2.165l-.2.115a.5.5 0 0 1-.683-.183l-1.125-1.949a.5.5 0 0 1 .183-.683l.2-.115c1.667-.962 1.667-3.368 0-4.33l-.2-.115a.5.5 0 0 1-.183-.683l1.125-1.949a.5.5 0 0 1 .683-.183l.2.115c1.667.963 3.75-.24 3.75-2.165v-.23a.5.5 0 0 1 .5-.5zm-2 .5a2 2 0 0 1 2-2h2.25a2 2 0 0 1 2 2v.23a1 1 0 0 0 1.5.866l.2-.115a2 2 0 0 1 2.731.732l1.125 1.949a2 2 0 0 1-.732 2.732l-.2.115a1 1 0 0 0 0 1.732l.2.115a2 2 0 0 1 .732 2.732l-1.125 1.949a2 2 0 0 1-2.732.732l-.199-.115a1 1 0 0 0-1.5.866v.23a2 2 0 0 1-2 2h-2.25a2 2 0 0 1-2-2v-.23a1 1 0 0 0-1.5-.866l-.2.115a2 2 0 0 1-2.732-.732l-1.125-1.949a2 2 0 0 1 .732-2.732l.2-.115a1 1 0 0 0 0-1.732l-.2-.115a2 2 0 0 1-.732-2.732l1.125-1.949a2 2 0 0 1 2.732-.732l.2.115a1 1 0 0 0 1.5-.866v-.23zM12.25 10a2.25 2.25 0 1 1-4.5 0 2.25 2.25 0 0 1 4.5 0zm1.5 0a3.75 3.75 0 1 1-7.5 0 3.75 3.75 0 0 1 7.5 0z" clip-rule="evenodd"/></svg></svg> **Queue settings**. {#settings}
   <!-- endsource: en/_includes/transition-page.md -->

1. In the left panel, select **Automation**.

1. <!-- source: en/_includes/create-trigger.md -->
   In the top right corner, click **Create** → **Trigger**. {#create-trigger}
   <!-- endsource: en/_includes/create-trigger.md -->

1. Enter a name for the trigger.

1. Set the trigger to fire when the issue's **Status** changes:

    - Trigger conditions: The issue status has changed to **Ready for testing**.

    - If you want a new assignee to be picked after a status update, add the trigger condition: specify the tester in the **Assignee** field.

   ![](_assets/trigger-example-status.png =650x){.border-yes}

Let's take another example, when one developer focuses on the server part of your product, and another developer works on its client part. Whenever any new errors relating to the server or client part arise, you can automatically set the responsible developer as an assignee using components and triggers:

1. In your queue, [configure the components](https://yandex.com.tr/support/tracker/en/manager/components.md) that refer to the **Server** and **Client** sides of the product. When creating a new error, add a relevant component to it right away.

1. Set up a trigger for server part errors:

    - Trigger conditions: the value in the **Components** field changed to **Server**.

    - Trigger action: specify the server side developer name in the **Assignee** field.

    ![](_assets/dev-process-trigger-component.png =650x){.border-yes}

1. Set up a similar trigger for errors in the client part:

    - Trigger conditions: the value in the **Components** field changed to **Client**.

    - Trigger action: specify the client side developer name in the **Assignee** field.

For an example of how to set up a trigger to fire when the component changes, see [Automatically assign an issue assignee](https://yandex.com.tr/support/tracker/en/manager/trigger-examples.md#assign_ticket).

## Reminding the assignee about the deadline {#auto-remind-deadline}

To make sure that your assignees adhere to deadlines, you can send them reminders using automatic actions. An automatic action triggers automatically and updates the parameters of issues that meet your criteria.

Say, for example, that you need to check all issues in your queue once a day. If the issue is still pending, and the date specified in the **Deadline** field occurs in less than three days, you should update the issue with a comment and invite the assignee. For this, set up the following automatic action:

- Auto action type: **Issue update**.

- Frequency: Once per day.

- Filter parameters: a query written using the [query language](https://yandex.com.tr/support/tracker/en/user/query-filter.md):

    ```
    Resolution: empty() AND Deadline: <= today() + 3d
    ```

    ![](_assets/autoaction-example-condition.png =500x){.border-yes}

- Issue action: send a comment and invite the user specified in the **Assignee** field.

For detailed instructions on how to set up auto actions, see [Auto update example](https://yandex.com.tr/support/tracker/en/user/autoaction-example.md).

## Creating recurring issues {#auto-create-task}

If you need to create issues by a template from time to time, you can use actions for this. For example, every week you can create an issue for data backup.

For this, set up the following automatic action:

- Auto action type: **Issue creation**.

- Frequency: Once a week on Fridays.

    You can set the start and end dates of the interval within which the issues will be created automatically. It's no such interval is set, the issues will be created indefinitely.

    ![](_assets/dev-process-autoaction-schedule.png =500x){.border-yes}

- Queue action: Create an issue. Fill in the fields of the automatic issue creation template.

For more information on how to set up recurring issues, see [Setting up issue creation](https://yandex.com.tr/support/tracker/en/user/ticket-schedule.md#setup).
