In its most basic form, an automation rule consists of two components: the trigger and the action. The trigger will determine when the automation task will run. There are three built-in trigger types:

• Issue triggers: These triggers run when the corresponding issue fires an event, usually when issues are updated in some way, such as during issue updates and workflow transitions.
• Scheduled: This trigger type will automatically run on a predetermined time frame. You can use the simple form, as we have in this recipe, to specify the frequency, or you can use a cron expression to specify the exact hour, minute, and second.
• Integrations: This trigger type creates a webhook URL. When an external system makes an HTTP POST request to the URL, the trigger will run.

The action is what will happen when a trigger runs. A trigger can run more than one action. An action can perform operations, including making changes to issue data, sending email notifications, and sending outgoing HTTP POST requests.

You can add more advanced components to your automation rule to have conditional branching and execution. For example, when a trigger is run, you can run one action for issues of type Bug, and another action for issues of type Story. You can also chain your automation rules so that one rule has a trigger based on a webhook, and you can have another rule with an action that makes an HTTP POST to that webhook URL to trigger it.

With our automation rule, we have set up a trigger to run once every day. We then used a JQL query to select only the issues in the Support Desk project that have not been updated in the last 7 days since the task was run. We then added an action for the trigger to transition all the issues returned from the JQL query to Done.