Settings

Purpose: Walk the two Settings surfaces — organisation scope (credentials, org-wide options) and project scope (how the project uses the org's integrations, modules, and people).

Organisation Settings — where org-wide config lives

From Home, with the right organisation selected in the header, open Settings (the gear icon). The left sidebar lists:

Sidebar item	What it does
Return to projects	Back to Home.
Dashboard	Organisation analytics — see Organization Dashboard. Shown only when you have analytics access for this organisation.
General settings	Edit the organisation name. Use Save changes when you have permission to update the organisation.
Integrations	Create and edit organisation-level integrations (issue tracking, version control, design system). Projects do not redefine credentials here; they select which org integration to use when creating or editing a project.
Audit log	Not available in this release; the sidebar entry is reserved for later.

General settings

Single-form page. Edit the organisation name and press Save changes. The Save button is disabled if your role does not permit organisation updates.

Integrations (at the organisation level)

This is where the credentials for every external tool live. Per-category, the org admin configures one or more integrations and gives each a human-readable name; projects then pick one of those names when they need that capability.

Per the Swifter Environment reference, the supported integrations are:

Category	Required?	Supported integrations
Issue tracking	Required	Azure DevOps Boards · Jira
Version control	Required	GitHub · Azure DevOps Git · Bitbucket · GitLab
Design	Required (for Frontend modules)	Figma
CI	Optional	Jenkins
SSO	Optional	WorkOS

Each integration's setup detail is documented in Setup → Swifter Environment — the Settings UI here is the visual surface; the setup steps (PAT scopes, branch policies, OAuth scopes) live in that page.

Audit log

Sidebar entry exists but is not available in this release — the platform will surface organisation-level audit events here in a future version.

Project Settings — how this project uses org-level config

From the project Workspace, open Settings in the header. The left sidebar lists:

Sidebar item	What it does
Return to project	Back to the project Workspace.
Project settings	Project-scope configuration (the first item on the sidebar) — see below.
People	Member list and roles — see below.

Project settings — the form

The Project settings page is one form with the same fields as Create a project, with three behaviour rules:

• Project name — editable when you have project update permission.
• Issue tracking and Design system integrations — editable; pick from the integrations the org admin configured.
• Version control system — fixed for the project after creation. Shown for reference but not editable; if you need a different VCS, the project must be recreated.
• Modules — existing modules are listed read-only; you cannot edit or remove them from this page. You can add new modules with the same field set the Create-new-module dialog uses.
• Work item query predicate — editable; filters which work items come across on Sync with issue tracker (WIQL WHERE clause for Azure DevOps; JQL for Jira; leave empty to use the tracker's default).

Press Save changes when the form is enabled.

People — members and roles

Paginated member list with search and role filter. Three actions are available, all gated by your own role:

Action	Who can do it
Add people	Project admins (when the organisation allows project updates)
Remove a member	Project admins
Switch between project admin and product engineer	Project admins

The platform never leaves a project without an admin. The last project admin cannot be removed or demoted until another admin is assigned — the UI greys out the controls until you nominate a replacement.

The two project roles

Role	What they can do
Project admin	Edit Project settings (name, integrations, modules, work-item query) and manage People (when the organisation allows updating projects). The user who creates the project is automatically the first project admin.
Product engineer	The default role for added members. Works inside the Reqs / App / Dev / Test tabs and the agent chat. Grant project admin if they need to manage Project settings or membership.

The role only affects what you can edit in Settings — both roles see the same Workspace, the same backlog, the same agent chat. Promoting someone to project admin is reversible.

When to use each surface

Scenario	Which Settings
Adding a new Git host / Figma file for the whole organisation	Organisation → Integrations
Changing a project's display name	Project → Project settings
Adding a developer to a specific project	Project → People → Add people
Granting an analyst admin rights on a project	Project → People → switch role to project admin
Filtering which work items sync from the tracker into this project	Project → Project settings → Work item query predicate
Viewing org-wide analytics	Organisation → Dashboard
Adding a new module to an existing project	Project → Project settings → Modules → add

If you cannot find the control where you expect it, the most common reason is permission — try the same flow from a project-admin account.