Built-in Automations
SetGet includes two built-in automation features that handle common project hygiene tasks without requiring you to create custom automation rules. These features are configured in Project Settings > Automations and operate independently of the rule builder.
Overview
| Feature | Purpose | Default state |
|---|---|---|
| Auto-Archive | Archive issues that have been inactive for a configurable number of days | Disabled |
| Auto-Close | Close issues that remain in a specified state for a configurable number of days | Disabled |
Both features are project-level settings. Each project can have its own configuration independent of other projects in the workspace.
Accessing built-in automations
- Open the project you want to configure.
- Go to Settings in the project sidebar.
- Select the Automations tab.
- The built-in automations section appears at the top of the page, above the custom rules list.
Auto-Archive
Auto-Archive automatically archives issues that have been inactive beyond a configurable threshold. This keeps your active views clean by removing stale items that no one is working on.
How it works
- The background scheduler checks all active issues in the project periodically (every 24 hours).
- For each issue, it calculates the number of days since the last activity (update, comment, state change, or any property modification).
- If the inactivity period exceeds the configured threshold, and the issue is in a qualifying state, the issue is archived.
- Archived issues are removed from active views but preserved in the project's archive section.
Configuration
| Setting | Description | Default |
|---|---|---|
| Enable Auto-Archive | Toggle to enable or disable | Disabled |
| Inactivity threshold | Number of days without activity before archiving | 30 days |
| Inactive states | Which state groups count as "inactive" for archiving purposes | Completed, Cancelled |
To configure Auto-Archive:
- In the built-in automations section, find the Auto-Archive card.
- Toggle the switch to Enabled.
- Set the inactivity threshold by entering the number of days (minimum 7, maximum 365).
- Select which state groups qualify for auto-archiving.
- Click Save.
State group eligibility
Auto-Archive only applies to issues in the selected state groups. This prevents active work from being accidentally archived.
| State group | Recommended for Auto-Archive | Rationale |
|---|---|---|
| Backlog | Optional | Stale backlog items may indicate abandoned ideas |
| Unstarted | Optional | Items never picked up may be candidates for archival |
| Started | Not recommended | Active work should not be auto-archived |
| Completed | Recommended | Done items can be safely archived after a period |
| Cancelled | Recommended | Cancelled items are natural archive candidates |
WARNING
Enabling Auto-Archive for the "Started" state group can archive items that are actively being worked on but have not been updated recently (for example, a long-running task). Use this setting with caution.
What counts as activity
The following actions reset the inactivity timer for an issue:
| Action | Resets timer |
|---|---|
| Any property change (state, priority, assignee, label, dates) | Yes |
| Comment added | Yes |
| Attachment added | Yes |
| Reaction added | No |
| Viewed by a user | No |
| Mentioned in another issue | No |
Restoring auto-archived issues
Auto-archived issues can be restored at any time:
- Go to the project's Archive section.
- Find the issue (use search or browse).
- Click Restore.
- The issue returns to its previous state and reappears in active views.
TIP
When an issue is auto-archived, an activity entry is added noting "Archived by Auto-Archive automation". This makes it easy to distinguish automatic archival from manual archival.
Auto-Close
Auto-Close automatically transitions issues to a closed (completed) state when they remain in a specified state for longer than a configurable number of days. This is useful for states like "In Review" or "QA" where items should not linger indefinitely.
How it works
- The background scheduler checks issues in the project periodically (every 24 hours).
- For each issue in the monitored state, it calculates how many days the issue has been in that state.
- If the duration exceeds the configured threshold, the issue's state is changed to the project's default completed state.
- A notification is sent to the issue's assignees and subscribers.
Configuration
| Setting | Description | Default |
|---|---|---|
| Enable Auto-Close | Toggle to enable or disable | Disabled |
| Monitored state | The state to watch for stale items | (none -- must be selected) |
| Day threshold | Number of days in the monitored state before auto-closing | 14 days |
| Target state | The state to transition to (must be in the "completed" state group) | Project's default completed state |
To configure Auto-Close:
- In the built-in automations section, find the Auto-Close card.
- Toggle the switch to Enabled.
- Select the monitored state from the dropdown (shows all states in the project).
- Set the day threshold (minimum 1, maximum 365).
- Optionally change the target state (defaults to the project's default completed state).
- Click Save.
Example configurations
| Scenario | Monitored state | Threshold | Target state |
|---|---|---|---|
| Close stale reviews | In Review | 7 days | Done |
| Close abandoned QA items | QA Testing | 14 days | Done |
| Close unresponsive items | Waiting for Response | 30 days | Cancelled |
| Close forgotten drafts | Draft | 60 days | Cancelled |
Multiple monitored states
You can monitor multiple states by adding additional Auto-Close configurations. Click Add State in the Auto-Close card to add another monitored state with its own threshold and target state.
| Monitored state | Threshold | Target state |
|---|---|---|
| In Review | 7 days | Done |
| Waiting for Response | 30 days | Cancelled |
| QA Testing | 14 days | Done |
Notifications
When Auto-Close transitions an issue:
- All assignees receive an in-app notification.
- All subscribers receive an in-app notification.
- The activity log records: "State changed to Done by Auto-Close automation".
- If email notifications are enabled for state changes, email is also sent.
TIP
Consider adding a comment action to your Auto-Close configuration to explain why the item was closed. This helps team members understand the automated action when they review the issue later.
Enable and disable
Both built-in automations can be enabled or disabled independently at any time.
| Action | Steps |
|---|---|
| Enable | Toggle the switch to on, configure settings, save |
| Disable | Toggle the switch to off, save |
| Temporarily pause | Toggle off without changing settings; toggle back on later |
Disabling a built-in automation does not undo any actions it has already taken. Previously archived or closed issues remain in their current state.
Interaction with custom rules
Built-in automations and custom automation rules operate independently but can interact in important ways.
Execution order
- Built-in automations run during the daily background scheduler cycle.
- Custom rules with scheduled triggers also run during their configured schedule.
- There is no guaranteed execution order between built-in and custom rules within the same scheduler cycle.
Potential interactions
| Scenario | Behavior |
|---|---|
| Auto-Archive archives an issue that a custom rule would match | The custom rule does not act on archived issues (they are excluded from active scope) |
Auto-Close changes state, triggering a custom state_changed rule | The custom rule fires normally, evaluating its conditions against the newly closed issue |
| A custom rule re-opens an issue that Auto-Close closed | Auto-Close will close it again on the next cycle if it still meets the threshold criteria |
| A custom rule archives an issue before Auto-Archive runs | Auto-Archive skips already-archived issues |
WARNING
If a custom rule re-opens auto-closed issues, and Auto-Close is still enabled with the same configuration, the issue will be closed again on the next cycle. This creates a loop. To prevent this, either disable Auto-Close for that state or add a label exclusion to your custom rule.
When to use built-in vs custom rules
| Use case | Recommendation |
|---|---|
| Simple time-based archival of completed items | Built-in Auto-Archive |
| Simple time-based closing of stale items | Built-in Auto-Close |
| Archival with complex conditions (specific labels, priorities, assignees) | Custom rule with scheduled trigger and archive action |
| Closing with notification to specific users | Custom rule with scheduled trigger, change_state and send_notification actions |
| Any event-driven automation | Custom rules (built-in automations are time-based only) |
TIP
Start with built-in automations for basic hygiene. Upgrade to custom rules when you need more control over conditions, actions, or notification recipients.
Related pages
- Automation Rules -- Creating custom automation rules
- Triggers -- All trigger types including scheduled
- Actions -- All available automation actions
- Scheduling -- Advanced scheduling with cron
- Execution History -- Reviewing automation activity
- Project Settings -- All project configuration options