Project profile settings
Project admins can update a project’s display name from project settings. Use the name for clear navigation and reporting. To change the sidebar emoji or project color, click the project icon in the sidebar and choose from the searchable picker. Changing a project name updates the visible label without changing the underlying task history. If your team or agents rely on stable project IDs, keep using IDs in API and automation flows.Task fields
Tasks can include:- Title and Markdown description
- Status
- Priority
- One or more assignees
- Project, team, milestone, and labels
- Start date and due date
- Dependencies
- Subtasks
- Attachments
- Recurrence
Task detail views
Open a task from the board, list, or full task page to review and update its details. The task detail modal and full page both expose the task URL copy action, so you can share the current task without leaving the view you are working in. On the full task page, Back returns to the view where you opened the task, with its filters and scroll position. If you open a task directly, in a new tab, or from an external page, Back to board opens that task’s project board. For a task with no project, Back to projects opens the workspace project list. Task detail also shows who created the task. Use creator and assignee context together when you need to understand who opened the work, who owns the next step, and who should be notified before closing or changing direction.Context
Task Detail and Project Detail include a compact Context section for authorized Atoll-owned Artifacts and external references. Artifacts are structured documents such as research, decisions, plans, and release checklists. The Context section loads Artifact metadata first; content loads only when you open an Artifact. Choose Artifact source when you create or edit a document to select an External Reference already in that Context. Keep the current source, select a replacement, or choose No source. Each save creates a revision with its own source snapshot. Open revision history to inspect earlier sources. If the live reference is removed, the snapshot remains and shows No longer linked in Context. Source links are visible only to readers who can access the recorded source issue or project. Atoll does not copy or synchronize external content. Open an Artifact to read its current sanitized revision, view immutable revision history, or use its direct link. Editors and admins with write access can create an Artifact, revise its title or content, link an existing Artifact to the current task or project, and unlink it. Read-only members can view authorized Artifacts but do not see these mutation controls. Revision saves use the current revision as a concurrency check, so a stale editor must reload before saving.External references
Task Detail and Project Detail also include authorized external references. Link a supported GitHub pull request by pasting its URL. Atoll resolves the provider identity server-side before it stores the reference; the URL you enter is not treated as the reference identity. Each canonical reference shows its object type, authority location, provider provenance, last-observed freshness, and whether it is currently resolvable. The external-reference list is an index only. It does not load pull-request content. Editors and admins can unlink a canonical reference when they have write access to its task or project. Existing task PR links remain visible in the Pull requests section with a Legacy label during the compatibility period. The section is hidden when empty. These records are read-only in the Context view and are not canonical External References. They do not provide provider identity or provenance for the canonical reference model.Strategy links
Projects and tasks can connect execution back to Strategy. Project overview shows linked initiatives when the project is explicitly tied to an initiative or when project tasks are linked to initiatives. Issue detail shows initiative chips for strategic work, and task creation can include an initial initiative link. When the right initiative does not exist yet, create it inline from the task modal and Atoll selects it for the new task. Use strategy links when a task exists to move a KPI or deliver an initiative. Leave routine operational work unlinked unless it truly affects a strategic objective.Statuses
Default statuses are:
Projects can define custom board columns from Board settings. The API also
accepts a project’s configured status values, and
cancelled is always valid.
For CLI usage, see Issues, comments, and projects.
Board Settings also lets project editors and admins classify each column for
future start-work recommendations: Candidate (may be started), Active (already
started), or Excluded (do not recommend). New projects use Backlog = Excluded,
Todo = Candidate, In Progress = Active, and Done = Excluded. Existing columns
remain unconfigured until an editor saves a role. An unconfigured column is
not eligible for future recommendation consumers, and a project with no
Candidate column shows a Board Settings warning before that configuration can
be used for start-work recommendations. The system cancelled status is always
excluded and is not configured as a column role.
Priorities
Assignees
Tasks support multiple assignees. Use one assignee when ownership is clear. Use multiple assignees for collaborative work where all participants need notifications and visibility.Dependencies
Dependencies express blocking relationships. A task can be blocked by another task or can block another task. Use dependencies when task order matters:done column
when the release-point migration runs. During a rolling deployment, an older
dependency row may omit release fields; treat that row as the legacy
open-blocker behavior until the migration is applied.
If a blocker moves to another project, Atoll asks for an explicit destination
release column for every dependency before it commits the move. Board Settings
also shows separate issue and release-reference counts before a column is
deleted, and requires independent destinations when either count is non-zero.
Recurring tasks
Recurring tasks can repeat daily, weekly, biweekly, monthly, or on a custom day interval. Scheduled intervals can be at most 10,000. Completion mode keeps its existing interval range. By default, when a recurring task is marked Done, Atoll creates the next instance and advances its due date according to the recurrence settings. To create occurrences while the current task remains open, set Create next task to On schedule, then choose a local time and IANA timezone. The maintenance sweep creates one occurrence at a time and preserves the schedule across daylight-saving changes. The root task owns the schedule; each generated task remains in the same recurrence chain. In scheduled mode, an archived root or disabled schedule is skipped, and a transient failure remains recoverable for a later sweep. Completing a scheduled occurrence does not create another task. During a daylight-saving overlap, Atoll uses the earlier instant. A nonexistent local time moves forward by the size of the gap. The schedule controls when tasks appear. Due dates continue separately from the root’s due date using the existing date recurrence. For example, a weekly task can appear on Monday and remain due on Friday. The root’s due date stays unchanged. Editing its due date resets future deadline progression without changing the appearance clock. Changing the appearance time or timezone preserves the calendar cadence and deadline progression. Selected weekly days also apply to the due-date cadence. Monthly creation keeps the original day of the month and uses the last day in shorter months. If task creation is denied, its target is missing, or its saved inputs are invalid, that scheduled occurrence is recorded as failed and is not retried. Correct the access or settings for future occurrences. Temporary failures and uncertain creation results remain recoverable on a later sweep. Once a chain has entered scheduled mode, recurrence edits on a generated task update the root, even after a switch back to completion mode. Such chains follow the root’s current mode. A disabled root in such a chain or an inaccessible root does not create a successor. Other task edits stay on the generated task. Send root recurrence changes separately from other task edits. You must have write access to the root to change its schedule. Deleting the root leaves scheduled-mode generated tasks as ordinary tasks; they do not become schedule owners. Completion-mode tasks retain their existing recurrence behavior after root deletion. Chains that have never entered scheduled mode keep and edit each occurrence’s completion settings locally. Switching one to scheduled mode adopts that occurrence’s cadence on the root. Switching modes preserves selected weekdays. Weekday arrays and weekly completion in completion mode remain temporarily unavailable;null can still clear selected weekdays.
For CLI usage, see Issues, comments, and projects.