Tasks & views
Inside every project, your team tracks work in two related ways:
- A task is a single piece of work — a bug, feature, chore, or subtask — with an ID, owner, status, and optional dates and labels.
- A view is a saved way to look at those tasks — filtered and laid out so you can open "my work", "blockers", or "this release" without rebuilding filters every morning.
Think of tasks as the backlog and views as the lenses your team reuses for standup, triage, and release planning.
This page is about day-to-day delivery in the Projects app — not company billing, model catalogs, or connecting GitHub (see Projects overview and GitHub integration).
What this page is for
You only see tasks for projects you belong to. Org admins see all projects; everyone else sees work scoped by Project members.
Understand tasks and views at a glance
Typical path for one piece of work:
- Create a task in the project (title, category, priority)
- Assign an owner when someone picks it up
- Move status as work advances — In progress → In review → Done
- Link an agent run or PR when automation or code review is involved
- Use a view so the team sees the same slice in standup without manual filtering
Most contributors spend their day in one or two views and update tasks as status changes.
Tasks vs views
These are easy to confuse:
You need tasks to track work. You need views so nobody rebuilds the same filters before every standup.
Teams that ship smoothly usually pin My active work (personal), Blockers (shared), and Release candidate or This cycle (shared). Add more only when a ritual needs its own lens.
Choose the right layout
Pick a layout for what you are trying to do, not just what looks nice:
Save the combination as a view once the team agrees on it.
Status, category, and priority
Three fields often get mixed up:
Example: A bug (category) can be urgent (priority) and in review (status) at the same time. Update status when the PR merges; keep category for reporting.
Who can see and change what
Shared views appear in everyone's view picker. Personal views stay on your account. Some orgs limit who can publish shared views — ask a project admin if save is disabled.
Why tasks and views matter
How tasks and views fit together
Typical flow: create task → assign and prioritize → move through status → link agent run or PR → Done.
In practice
Task status
Move tasks and subtasks through statuses as work progresses:
Priority and dates
Optional start, due, and target dates power Timeline and Calendar views. Use milestone or cycle fields when your team plans in fixed iterations.
Break epics into a parent task and subtasks (for example ATL-184 and ATL-184-a).
Each subtask moves through the same statuses and shows on the board under the parent.
Create and update tasks
Create a task
In the project, choose New task. Add a title, category (bug vs feature), and priority. Assign an owner when someone commits to it.
Move status as work advances
Update status when work starts, enters review, blocks, or completes. Keep assignee current so shared views stay accurate for standup.
Add context
Use description, labels, dates, or milestone so the next person — or the agent — knows what "done" means.
Link agent or PR work
When an agent run addresses this task, link it so reviewers see summary and PR context on the ticket.
Close the loop
Move to Done when accepted, or Canceled if it will not ship — history stays in the project.
Views
A view = filters (which tasks) + layout (how they look) + group + sort.
Save a view for the team
Filter to the slice you need
Example: status In progress or Blocked, assignee me, due this week.
Pick layout and grouping
Board by Status for Kanban; List by Assignee for standup.
Save and name it
Save view → name it clearly ("Eng standup", "Release blockers"). Choose personal or shared with project.
Keep the picker useful
Retire views nobody opens. Two or three shared views plus personal ones is enough for most teams.
Views teams often reuse
Agent and tasks
Agents run inside the project — same linked repos, models, and policy as human contributors. Tasks connect planning to automation:
Agent suggestions for task fields are advisory. Accept or edit in the task UI. Nothing moves to Done until your team agrees.
Runs from the desktop agent, CLI, or cloud agents can attach to a task so reviewers are not searching chat for context.
Fix common issues
When tasks or views feel wrong, check in order:
Can you see the project at all?
If not, you may not be on Project members — ask a project admin to add you.
Is the task in the project you expect?
Tasks belong to one project. Open the correct project from the Projects app.
Are filters hiding work?
Clear filters or switch views — a saved view may exclude Backlog or other statuses.
Is assignee or status stale?
Standup views depend on accurate assignee and status. Update tasks when ownership shifts.
Shared view missing or can't save?
Some orgs restrict shared views to leads and admins. Use a personal view or ask project admin.
Agent work not on the task?
Link the run when starting from the project. Confirm GitHub is connected if you expect PR links — see Troubleshooting.