Board Settings

Use board settings to plan one board and control its automatic behavior. Set its target and milestones, post health updates, mute notifications, or configure archival, staleness, time tracking, and assignment rules.

What this affects

Board settings apply to individual boards on a project. They govern default behaviors that are applied consistently across tasks when rules are triggered:

Archive actions — Automatically archive old tasks or mark them for archival to keep your board clean.
Project planning — Set a target date, track milestones, and post the board’s current health.
Board notifications — Mute ordinary inbox, email, and push notifications from this board only.
Staleness rules — Automatically detect tasks that have been idle for a set period and take action.
Auto-assign rules — Set per-column rules so new or unassigned tasks get attention where they belong.
Time totals — Optionally show accumulated tracked time on task cards and in table view.
Synchronized IndexedDB defaults — For authenticated Board and Table routes, the synchronized IndexedDB read model is now enabled by default to keep data in sync across opened tabs without manual refresh. You can still opt into the local model by using <code>?local_db=0</code> in the URL.

Reach

You can open board settings from:

Ctrl+K command palette — Search for “Board settings” and select your board.
Board menu — Open a board’s menu and choose Settings.

<CardGrid>
<Card title="Auto-archive" icon="folder">
Clear expired backlog and automate housekeeping.
</Card>
<Card title="Staleness detection" icon="timer">
Identify tasks that haven't moved recently.
</Card>
<Card title="Auto-assign rules" icon="user">
Propagate responsibilities to unassigned cards.
</Card>
<Card title="Synchronized IndexedDB defaults" icon="database">
Keep data in sync across browsers by default for authenticated board and table routes.
</Card>
</CardGrid>

Board notifications

Open Settings → Board → General, then turn Board notifications off to mute one board. The change applies immediately and persists across refreshes.

Muting a board stops its ordinary:

Inbox notifications, including snoozed items returning later.
Push notifications.
Immediate and digest emails.
Assignment, reaction, task-move, and due-date alerts.

Your global notification channel settings stay unchanged, and other boards continue notifying you. Direct replies from managed agents still appear in your inbox so an explicit agent request can return its answer.

Turn Board notifications on again whenever you want to resume delivery.

Project planning

Open Settings → Board → Planning to keep the board’s outcome and current health in one place.

Set the board’s target date.
Add dated milestones, then mark them complete as the project advances.
Post a short health update as On track, At risk, or Off track.
Review the 20 most recent updates with their author and timestamp.

Any board member can read planning and post a health update. Only the board owner or an admin can change the target date or milestones.

Target and milestone changes save immediately. Press Ctrl+Enter or Cmd+Enter to post a health update from the message field.

Auto-archive

Configure automatic archival of tasks that no longer require attention. Archive is different from deletion—it keeps history while removing items from the active view so you don’t have to manually clean up stale columns.

Available options

Rules you can set per board:

Enable auto-archive — Turn the rule on/off.
Archive after — Choose how many days tasks remain before archival.
- Common presets: 90, 120, 180, 365.
Archive unused — Automatically archive tasks that have not been touched recently (see Staleness).

How it behaves

When a task crosses your configured threshold:

The board removes the task from column counts.
Tasks are moved to the board’s Archive section.
History (comments, attachments, subtasks) remains intact.

Tasks in any column are eligible: backlog, in-progress, review, and so on.

Staleness detection

Staleness rules keep track of active tasks that have not been moved, updated, or interacted with in a defined window. This helps surface forgotten items that might need re-evaluation or removal.

Configuration:

Stale after — Number of days since the last change/due date.
- Suggested ranges: 30, 60, 90.
Auto-assign stale tasks (Optional) — Toggle the rule that moves or re-assigns stale tasks to a specific column or assignee.
Stale reminders (Optional) — Get notified when tasks reach the staleness threshold so you can prioritize review or cleanup.

When staleness is enabled, stale Kanban cards show the task’s age on the board before its age in the current column. Use Ctrl+K to toggle staleness for the board or the current view.

Filtering stale vs healthy

Every staleness filter is named so that typing stale in the filter menu finds all of them:

Stale in column — days since the task last changed column, falling back to its creation date if it has never moved.
Stale without comment — days since the last comment, falling back to creation if nobody has ever commented.
Stale on board — days since the task was created, regardless of activity (not affected by column moves or comments).
Not stale — the inverse: both the column age and the comment age are under the warn threshold. This deliberately ignores board age: a long-lived task that is still being moved and discussed is not stale.

All four filters apply the per-board staleness threshold automatically, so a filtered board always agrees with the ages shown on the cards.

Auto-assign rules

Define rules that automatically assign or re-assign tasks to specific members. This is useful for ensuring that new pull requests, backlog items, or triage items land with the right people without manual overhead.

Per-column auto-assign on column move

In addition to setting a default for the entire board when a task is created or is unassigned, you can configure a per-column auto-assign rule: whenever a task is moved into this column, it will be assigned to the specified person or group. Ctrl+K “Auto-assign for this column” opens the per-column configuration.

To configure per-column auto-assign:

From the board or section header, open the context menu (or use Ctrl+K “Auto-assign for this column”) and select the section where you want the rule.
Pick an assignee (group or individual) to apply as tasks are moved into that column. The assignment is additive and idempotent—moving a task back into another column and then into this column again respects the rule.
When the rule applies, all tenants receive a notification and the assignee is messaged in the source channel if notifications are set up for the board.

Auto-assign on task creation (HTPR-5488)

The per-column auto-assign rule now also applies to tasks created directly in a column. Previously, auto-assign only ran when tasks were moved; tickets filed straight into a column (via the bottom-of-column composer, from an inbox, or through CLI) would not be assigned. Now, any new task that lands in a column respects the column’s auto-assign rule, whether it’s moved in or created there directly.

How to configure (defaults)

Target columns — Specify which columns should apply auto-assign triggers:
- Any column that can receive tasks (e.g., In Progress, Review).
Assign to — Select a project member or a role-based assignment:
- Individual users.
- Groups (e.g., “Testers,” “Backend team”).
Optional priority filter — Apply only to tasks with certain priority levels (e.g., Urgent, High).

Scenarios

Backlog channel — Assign new backlog items to reviewers or maintainers.
Review overload — Auto-assign completed items to QA reviewers when they become “In Review”.
Slack alerts — Combine with board notifications to alert assignees when auto-assign runs.

Autosave drafts

Changes to board settings are saved automatically. If you navigate away or refresh the page, your settings persist:

No manual save needed — All toggles, number inputs, and column mappings are applied instantly.
Revert behavior — If you make a mistake, the board defaults (detected from project/staleness rules) can be used as a backup; update the offending rule and save again.

Logging and history

Hypertask tracks rule executions at the board level for review:

Rule runs — Historically, Hypertask logged rule runs to a log table (Admin role visible).
Rule hygiene — To keep logs manageable, Hypertask retains only recent rule executions (e.g., last 14–30 days) on the log table, while preserving a full backup in a more extensive repository for administrative use.

Synced IndexedDB defaults (HTPR-5260)

You can choose between two read models for Boards and Tables:

Synchronized IndexedDB (default) — Active when no <code>?local_db=0</code> in the URL. Keeps data in sync across opened tabs and browsers smoothly, at the cost of higher CPU and a small memory overhead. Use this if you regularly open the same board in multiple tabs or devices.
Local IndexedDB (optional) — Activated by appending <code>?local_db=0</code> to the URL. Reads and writes stay in the local browser state, giving high performance with less CPU and a smaller footprint. Data may not reflect changes from other tabs or browsers until you reload.

This defaults to the synchronized model for authenticated Board and Table routes. The system preserves the opt-out via URL flags, so local flow can still be opted into for testing or performance-sensitive workflows.

Auto-error routing targeting Bugs (HTPR-5386)

When auto-error tickets are routed to sections, Hypertask now targets the exact Bugs section by default instead of the board’s default column. This applies globally for boards with a specific Bugs section. Boards without a clearly defined Bugs section fall back to the current default section behavior. Changes take effect after board settings are saved.