Project Settings
The Settings page of a project: cadence, estimation, workflow, collaboration and alert knobs with their defaults, plus the danger zone.
By the end of this page you will have tuned a project's knobs once so every later module reads them rather than asking again, know every setting with its default and what reads it, and know how a project is archived, restored and deleted from its own settings.
A project's settings are the few things that differ from project to project without being part of its record: how long a sprint runs and on which days, which timezone its deadlines are read in, what work is sized in, what moves an item along, whether the client may comment, whether Heimdall assists, and where the project speaks when something happens. A project stores only the keys somebody changed; everything else is the workspace default.
Before you begin
| You want to | You need |
|---|---|
| Open the Settings page | project:update on the project, through your role on the project or your team role, or to own the team. Project managers have it; a client guest never does. |
| Delete the project | project:delete. |
| Change the approval policies | approval:manage-policies, through a project role or a team role. |
The page lives under a project: open the project and choose Settings in the sidebar. The entry appears only to people who may change the project.
Set the cadence
- Pick the Timezone sprint boundaries, deadlines and SLAs are read in, or leave it on the workspace default.
- Set the Sprint Length in days.
- Tick the Working Days; capacity, burndowns and SLAs skip the rest.
- Set when the Business Day Starts and Ends; incident and ticket SLAs count between them.
- Choose the Estimation Unit and, for points, the Story Point Scale.
Set the workflow
- Choose the Default Assignee a new item goes to when nobody is named.
- Switch on or off whether an opened pull request moves an item to review, whether a merged one moves it on, whether a story needs its Definition of Ready before a sprint takes it, and whether an item needs its Definition of Done before it is done.
These take effect as the board, the sprints and the Git integration land; setting them now means those modules start the way the project wants them.
Set collaboration and alerts
- Decide whether Guests may comment and whether Heimdall assists on this project.
- Paste the Telegram Group Chat id that should receive the project's alerts, or leave it empty.
- Decide whether a production environment found down twice should open an incident once the maintenance module lands.
Press Save Settings. Only the keys that differ from the workspace defaults are stored, every
module reads the merged result, and project.settings_changed goes out with the keys that
changed. Restore Defaults puts the workspace defaults back on the form without saving them;
press Save Settings to keep them.
Defaults are the workspace's, not the project's
A key you never touched follows the workspace default, so a change to the default later reaches every project that never overrode it. A key you set stays as you set it.
Seat the council
Under The Council, tick the voices of Heimdall's council that sit on each open moment of this project (the Intake scaffold on a brief import, the Requirement review on a story, requirement or rule), each voice shown with its lens, and set the Council Budget Share: the percentage of the team's monthly AI budget the council may spend on this project, 1 to 100. Every voice of a moment sits by default; a moment with no voice ticked cannot be convened, and a voice left unticked is refused when asked for alone. A team without a cap is never refused on the share. Press Save Settings as for the rest.
Set the approval policies
Under Approvals, one editor per open kind of approval says who decides
it on this project, how many must agree and how long they have: the Rule and the Quorum,
the Approver roles, Named people and Stakeholder seats asked, the Hours to decide,
the Reminder after, the hours after which a request carries by itself, whether a refusal needs
a reason, and whether the gate is on at all. A kind nobody changed reads the workspace defaults and
says so with a Workspace default badge; Save Policy on an editor writes that kind alone and
turns the badge into Set on this project, and requests already open keep the approvers they
were sent to. The Requirement review, the Baseline approval, the Client sign-off and
the Change request are open today; the client sign-off takes its approvers from the stakeholder
seats flagged as approving requirements rather than from the policy's lists. The editors need
approval:manage-policies; everyone else who may open the page reads a summary. Every field is
explained on the approvals page.
The danger zone
At the foot of the page:
- Archive Project takes the project out of the registry's default view and keeps everything under it; Restore Project brings it back.
- Delete Project removes the project with every component, environment, person, term, entity,
design and repository under it. Type the project key to confirm; there is no undo. Only a person
with
project:deletesees it.
All the settings
What happens next
- Every save is written to the project's activity history with who did
it and where from, and
project.settings_changedgoes out with the keys that changed. - Every module that lands reads the settings from here: the sprint planner, the board, the Git integration, the SLA timers, the alert routing and Heimdall's assists.
Heimdall on this page
Heimdall reads the settings through the same tool the MCP server offers and carries the open project as its context.
Tuning a project is a person's work: an agent over MCP reads the settings to plan and size the way the project does, and never changes them.
From the API and MCP
Project Settings API
Read every setting with the defaults filled in, and change the keys you send.
get_project_settings
The MCP tool that reads a project's settings as the token sees them.
Permissions
| Action | Permission |
|---|---|
| Open and save the settings | project:update, through a project role or a team role |
| Read the settings over the API | project:view, staff only; a client guest is refused |
| Archive or restore | project:update |
| Delete the project | project:delete |
| Change the approval policies | approval:manage-policies |
Frequently asked
Related
- The registry — the project's own fields: name, key, client, leads, dates
- Environments — the health checks the incident switch reads
- Notifications — where personal alerts go beside the project's Telegram group
project.*webhook events
How is this guide?
Last updated on
Repositories
The Repositories tab of a project's Code pages: the Git repositories the code lives in, with provider, owner, name, default branch, privacy and component; registering, editing, disconnecting and deleting them.
Clients
The Clients page: the organisations your team does projects for, adding one with its contacts and status, editing it, archiving and restoring it, and why a client with projects is never deleted.