Program Settings

Added in 0.2 (alpha)

This page documents functionality added in TruePPM 0.2, available since the 0.2.0-alpha.1 pre-release (May 31, 2026). 0.2 is an alpha release; the first beta is planned for 0.4.

A program is a container for the related projects one PM or program manager runs together (ADR-0070). It is a Community (OSS) entity — programs group projects, roll their health up to a single view, and carry shared policy that their projects inherit. (Portfolio governance across multiple programs is a separate, Enterprise concern and is not configured here.)

Every program has a Settings area at /programs/:programId/settings — one scrolling page (ADR-0146) whose sections you can jump to from the settings nav: General, Projects, Access, External stakeholders, Rollup KPIs, Cadence, Working calendar, Risk & dependency policy, Attachments, Integrations, and Lifecycle.

Fields carrying jargon, a policy choice, or an inheritance cascade also carry a circled ⓘ contextual-help affordance that explains the setting and deep-links to the relevant guide. See In-product help for how it behaves.

Inheritance: workspace default → program override

Many program settings are not standalone values — they inherit the workspace default and can be overridden per program. When a program has no override of its own, the control reads Inherit (…) and shows the value it would take from the workspace. Set a value to override; clear it to fall back to inheritance. The settings that cascade this way are:

• Methodology (ADR-0107) and iteration terminology (ADR-0116)
• Estimation scale (ADR-0510)
• Sprint story picker “Ready only” default (ADR-0758) — ships in 0.4
• Public sharing and guest access (ADR-0135) — see Sharing & Access Inheritance
• Duration change → percent complete policy (ADR-0151)
• Monte Carlo forecast-history retention (ADR-0144)
• Attachment policy (ADR-0153)
• Working calendar (ADR-0441)

A workspace can also enforce some of these values so downstream scopes cannot override them. Enforce is an Enterprise capability — in the community edition an enforced policy degrades to a suggestion (no lock), so a program can always set its own value.

Access

Reading a program’s settings requires membership on the program. Writing them requires the Program Manager role or above — the program API gates PATCH /api/v1/programs/:id/ and the dedicated policy actions at the Admin tier. Program roles are the 5-role model (Owner, Admin, Scheduler, Member, Viewer), named on program surfaces as Program Admin, Program Manager, Resource Manager, Team Member, and Viewer, and are separate from project roles; see Roles & Permissions.

A closed program (see Lifecycle) is read-only shell-wide: every Add/Edit/Remove-style control across these settings sections is disabled or hidden — and says so — even for an Admin/Owner, because the underlying write is rejected server-side once the program is closed. Reopen the program to resume editing. Member removal on the Access section is the one exception: it stays available on a closed program, since removing a member is not itself blocked.

General

The General section edits the program’s identity and delivery model. Settings here affect every project in the program.

Field	Description
Program name	Display name shown across the program’s views.
Program code	Short prefix used for task IDs and exports (e.g. APOLLO-123).
Accent color	Program accent swatch used in nav and health chrome.
Description	Free-text summary of the program’s purpose.
Target date	The program’s headline target finish date.
Program lead	The one person named as accountable for the program. A display field only — it grants no access. Permissions come from a member’s program role (Program Admin, Program Manager, Resource Manager, Team Member, Viewer), set under Access.
Health	Manual health override (On track / At risk / Critical), or Auto to let the rollup compute it.
Methodology	Planning model new projects created in this program start with. It seeds new projects only — projects already in the program keep their own. See Methodology presets.
Iteration terminology	What the program calls its iteration container (Sprint, Iteration, Cycle…). Inherits the workspace default.
Estimation scale	The estimate scale (story points, hours, T-shirt…) projects inherit. Inherits the workspace default.
Story picker shows Ready stories only, by default (ships in 0.4)	Whether the sprint story picker starts filtered to Definition-of-Ready stories for this program’s projects. Advisory only — never a commit-time block. Inherits the workspace default.
Allow guests	Whether guests may be added to this program’s projects. Inherits the workspace value — see Sharing & Access.
Public sharing	Whether read-only view links may be shared. Inherits the workspace value.
Keep Monte Carlo run history	Whether the program retains past Monte Carlo forecast runs. Inherits the workspace policy.
Run history limit	How many forecast runs to keep before the oldest are pruned.
Run attribution visible to	Who can see which member ran a forecast. See Retention.
Duration change → percent complete	Whether editing a task’s duration re-derives its percent complete, and the override policy (ADR-0151). Inherits the workspace value.

Projects

The Projects section is a bulk matrix of the projects assigned to this program. It lets you review and set the methodology and iteration label across the program’s projects at once. See Methodology presets.

The program methodology seeds new projects; it does not flow down to existing ones. A project created in this program starts with the program’s methodology, and after that it keeps its own — changing the program’s methodology later leaves every existing project where it was. This matrix is how you move them. (The iteration label is different: it is a true nullable override, so clearing it on a project really does fall back to the program’s.)

After you save a methodology

Ships in 0.4

The post-save report described here ships in TruePPM 0.4, the first beta. In v0.3.0-alpha.3, the latest release, a methodology save on the General section says nothing about the projects already in the program — you have to open this matrix and read the rows yourself.

From 0.4, saving the Methodology on the General section will report the partition it left behind, immediately under the picker:

Saved. 9 of 12 projects in this program run as Waterfall; 3 do not. Existing projects keep their own methodology. Align the 3

Align the 3 will scroll you to this matrix with the Deviates from default filter already applied, those rows already checked and Methodology already chosen in the field picker. It will not stage a value, so Apply stays disabled until you pick one — the link takes you to the change, it does not make it. Where the program has no projects, or where every project already matches, the message will say that instead of showing nothing.

Seeing which projects deviate from the default

Ships in 0.4

The deviation markers, the column count, and the methodology filter described below ship in TruePPM 0.4, the first beta. In v0.3.0-alpha.3, the latest release, the matrix shows each project’s methodology and nothing about where that value came from.

Scanning a column of values tells you what each project runs on, not which ones are a deliberate exception. From 0.4 the matrix will answer that directly, at three levels:

• Per row. A project whose methodology differs from the one it would inherit will read Waterfall ≠ program (Hybrid) — its own value, then the scope it was compared against and that scope’s value. Rows that match show the value alone. The marker is text, so it survives print, monochrome, and a color-vision deficit.
• Per column. The Methodology header will carry the tally — Methodology · 12 differ. When every project matches it reads · none differ rather than · 0 differ.
• Across the list. A methodology filter above the matrix will narrow the list to one preset or to Deviates from default, with a count on every option. Changing it clears any selection you had made, so a bulk edit can never land on rows you can no longer see.

The comparison names the scope it actually made. Normally that is the program. Under a workspace Inherit methodology policy the workspace default wins at every scope, so the marker, the filter option, and the count all re-parent to the workspace — ≠ workspace (Hybrid), Deviates from workspace — and the header reads Methodology · read-only · 21 differ. A project that still differs under that policy is a pre-lock override the policy has not reconciled, which is worth seeing precisely because you cannot edit the column there.

All three are reads. They render for every role, including Viewer, and on a closed program, where the bulk-edit controls do not.

Deviates from the default is not the same as “someone chose this”

methodology is a non-null column at every scope, so a project explicitly set to Hybrid and a project nobody ever configured are identical on the wire. The marker therefore answers “does this differ from the value it would inherit?” — which is the question a scan is actually asking — and cannot tell you whether anyone made a decision. There is no stored provenance for methodology today.

On a screen narrower than 768px the matrix becomes a read-only card list: the markers, the count, and the filter stay, and the bulk-edit controls are replaced by a note that they need a wider screen.

Access

The Access section manages who can see and manage the program, using the 5-role model. From here an Owner/Admin can invite members, change a member’s role, and remove members. The last remaining Owner cannot leave until another Owner is assigned. Program membership is independent of the membership on the projects inside the program. See Roles & Permissions.

External stakeholders

Ships in 0.4

This whole section — the registry, its CRUD form, and the /external-stakeholders/ endpoints — ships in TruePPM 0.4, the first beta. It is not present in v0.3.0-alpha.3, the latest release. The nested callout below narrows further: the reach summary is the last part of the section to land.

The External stakeholders section is a registry of people without a TruePPM account — client sponsors, vendor contacts, external reviewers — kept as a separate recipient list for @program-stakeholders mentions. It is a first-class CRUD list, not a free-text field: each row has a Name, an Email (unique per program), and an optional Note, plus who added it.

They are deliberately not merged into the mention group itself, so an internal @program-stakeholders mention can never silently reach a client.

Who the alias actually reaches

Ships in 0.4

The reach summary described below ships in TruePPM 0.4 (the first beta), along with the mention-reach endpoint that computes it. Before 0.4 the section shows only a count of the external rows.

The two halves of the alias have different fates, and the reach summary above the table states both so you can see exactly who a mention touches:

• External contacts are listed only. No email or notification is sent to them yet — email delivery is a future, operator-enabled capability.
• Viewer-role members get an in-app notification. These are the members holding the Viewer role on any project inside the program, counted once each. If the program has no Viewer-role members, the summary says so plainly — the alias notifies nobody in-app.

Reading the summary requires the program Admin role, the same role that manages the list. The count comes from GET /api/v1/programs/{id}/mention-reach/, which returns the two arms separately and never a combined total.

Managing the list

Add a stakeholder with the Name / Email / Note form at the bottom of the list; a duplicate email within the same program is rejected inline rather than silently creating a second entry for the same person. Edit on a row opens it in place using the same fields as the add row — correcting a mistyped address is an edit, not a remove-and-re-add. Save commits the change and Cancel discards it; Save stays disabled until the name and a well-formed email address are both present, and a malformed address explains itself under the row rather than failing after a round trip. Remove asks for a one-click confirmation before it deletes a row.

Access

Reading and writing the list both require the program Admin role or above — managing who is externally pinged is treated as an administrative act, so Scheduler, Member, Viewer, and non-members cannot see or change it. Writes are additionally blocked once the program is closed (reads still work).

Endpoints

Method	Path	Access
GET	/api/v1/programs/{id}/external-stakeholders/	Program Manager+
POST	/api/v1/programs/{id}/external-stakeholders/	Program Manager+
PATCH	/api/v1/programs/{id}/external-stakeholders/{stakeholder_id}/	Program Manager+
DELETE	/api/v1/programs/{id}/external-stakeholders/{stakeholder_id}/	Program Manager+
GET	/api/v1/programs/{id}/mention-reach/	Program Manager+

Rollup KPIs

The Rollup KPIs section chooses which health signals roll up to the program level (ADR-0169). Only the KPIs you enable appear on the program overview. The available signals are Schedule health, Schedule variance (SV), Baseline variance, Critical task count, Milestone health, At-risk tasks, Risk score, P80 date, Cost variance (CV), and Budget utilization. An Aggregation policy controls how the member projects’ health combines into the single program health shown when General → Health is set to Auto. Editing the rollup config requires the Program Manager role or above. See Program rollup.

Three of those signals have no data source yet and are shown but locked: Cost variance (CV) and Budget utilization need project cost data, and P80 date needs stored Monte Carlo runs. Their switches cannot be turned on, and each row states why — enabling one would have saved a KPI that could never render a value. They unlock automatically once the backing data lands; no setting changes on your side. If a program enabled one of these before they were locked, the switch stays available to turn off so you can clear it, and the overview shows a dash with the reason instead of a number.

Cadence

The Cadence section defines the program’s recurring ceremonies — meeting templates such as steering reviews or demos. Each ceremony carries a name, cadence, duration, and owner, and an optional phase-gate calendar.

These are templates you record, not meetings TruePPM books. Nothing is scheduled, dispatched, or linked to a milestone on your behalf: saving a ceremony stores its definition, and saving a phase-gate invite template stores that text. Saving a phase-boundary milestone does not schedule a gate review — you still book the meeting yourself, and the template is there to paste from. The {{milestone.name}}-style placeholders are yours to fill in when you copy the text out; nothing substitutes them. Dispatch is tracked as #2983.

Working calendar

The Working calendar section sets the calendar the CPM engine uses to schedule the program’s projects (ADR-0441). It inherits the workspace default unless you override it here; a project can in turn override the program calendar. See Working calendars.

Risk & dependency policy

The Risk & dependency policy section governs cross-project risk within the program (#529):

• Slip policy — how a slip on a cross-project dependency propagates to the dependent project (warn or block). Default: warn.
• Auto-escalate after — how many days a cross-project dependency risk may go unaddressed before it escalates. Default: 3 days.

The risk-scoring matrix shown alongside these controls is a read-only reference. These policy values are direct program settings — they are not inherited from the workspace.

Attachments

The Attachments section controls whether task file uploads are allowed for this program’s projects and which file types are permitted (ADR-0153). It inherits the workspace attachment policy unless you override it here. External links are always allowed regardless of this setting. See Attachment policy.

Integrations

The Integrations section configures program-wide webhooks and API tokens, which fire across every project in the program. Project-scoped integrations live under each project’s own settings instead. See Webhooks and the MCP server.

Lifecycle

The Lifecycle section (shown as Archive / Close) holds the program’s lifecycle actions (#530). Every action here is logged and reviewable in the workspace audit log:

• Close / Reopen — end the program’s active phase, or reopen a closed program.
• Transfer sponsorship — hand the Program Admin role to another member. You step down to Program Manager, and can optionally reassign the program lead in the same step. The new Program Admin must already be a program member.
• Split into sub-programs — divide the program’s projects into new programs.
• Delete program — permanently remove the program. This is a destructive, confirmation-gated action; before deleting, consider exporting first — see Data export.

See also

• Programs — what a program is and how it groups projects
• Workspace Settings — the defaults programs inherit
• Project Settings — the scope below a program