Skip to main content

Projects and Scope

Projects separate work by product, customer implementation, business unit, initiative, or operating team. They give each area its own access model, workflow, custom fields, and saved boards while keeping the organisation connected.

Use a project when work needs any of these boundaries:

  • Different members or permission rules.
  • Different ticket workflow statuses.
  • Project-specific custom fields.
  • Saved boards for a team or operating rhythm.
  • A scoped roadmap.
  • Knowledge that should not be treated as company-wide context.

Create a Project​

Project managers and organisation administrators can create projects from project settings. A project needs:

  • Name: the human-readable name.
  • Key: the short issue-key prefix, such as APP or CS.
  • Description: the purpose or scope of the project.
  • Visibility: open or restricted.
  • Lead: the person responsible for operational ownership.
  • Workflow: the statuses and transitions tickets follow.

Project keys are stable identifiers. Choose a key that people can recognize in ticket references, TQL filters, board names, and reporting.

Project Scope​

The project scope picker controls which project context the app uses. Scope affects tickets, roadmap, decisions, risks, docs, memory, chat context, custom fields, and saved boards.

Use:

  • All Projects for company-wide review and cross-project search.
  • A selected project for focused execution, project-specific custom fields, project boards, and project-scoped roadmap work.

If information appears missing, first check the scope picker. The data may exist in another project, at organisation scope, or in a view filtered by TQL.

What Scope Changes​

Project scope affects:

  • Which tickets appear in boards and lists.
  • Which workflow statuses and transitions are available.
  • Which custom fields can be viewed, edited, or filtered.
  • Which saved project boards are available.
  • Which roadmap epics and proposals are shown.
  • Which decisions and risks are shown when they are project-scoped.
  • Which knowledge TOW uses for project-specific AI responses.

Scope should match the audience for the information. If a fact applies across the organisation, keep it at organisation scope. If it only applies to one initiative, customer, or product area, scope it to the project.

Docs can also live at organisation, project, group, or private scope. Their breadcrumb shows the current location before the title, such as Project TOW / Docs / Parent / Current. Moving a doc to another project or scope is recursive: its child docs move with it, and mixed-scope doc trees are not allowed.

Open and Restricted Projects​

Projects have two visibility models:

  • Open: organisation members can read and write project work.
  • Restricted: only users and groups with project access can read or write project work, except organisation administrators.
Open Project Write Access

An open project is not read-only. Organisation members receive write access to open projects even if they do not have a direct project grant. Use restricted visibility when project work should be limited to specific members or groups.

Choose open projects for broad internal operating work. Choose restricted projects for confidential initiatives, sensitive customer work, executive planning, legal matters, or any project where membership should be explicit.

Project Settings​

Project settings control:

  • Project identity, key, description, lead, and visibility.
  • Direct user access and group access.
  • Workflow statuses, categories, transitions, role rules, and required fields.
  • Project custom fields and field options.
  • Saved boards, TQL filters, card layouts, and visual styles.
  • Project-level Agent bindings for project-scoped AI actions and schedules.

Only users with project management access can change settings. Members who can write can still create and update tickets if the project visibility and role allow it.

The Agents link in Project Settings lets project managers tune project-scoped AI behavior such as roadmap generation, docs processing, ticket conflict scans, and operating pulses. Project settings inherit from server and organisation settings. A project cannot re-enable an Agent disabled by either higher level, but it can set a more specific schedule where scheduling is supported.

See Agent configuration for the full inheritance rules.

Archive Projects​

Archive a project when the project is no longer active but should remain part of the organisation record. Archiving a project is different from deleting tickets. It preserves historical project context while removing the project from active operating workflows.

Before archiving a project:

  • Resolve or archive active tickets where possible.
  • Confirm important docs, decisions, and risks have the right scope.
  • Export or report on project data if your process requires it.
  • Communicate where future work should be created.

Moving Tickets Between Projects​

Move tickets when work was created in the wrong project or needs to be owned by a different team. Move carefully because project configuration does not always match.

Project Moves Clear Custom Fields

When a ticket moves to another project, TOW clears its project custom fields, assigns a new issue key in the target project, and may adjust its status to the target workflow. If the ticket's parent is not moved with it, TOW detaches that parent relationship.

Review moved tickets after the move and fill in the target project's required custom fields, owner, and status.