Getting Started
Purpose: Cover the very first steps — sign in, land on Home, understand organisation-level configuration, confirm integrations are in place.
Sign In
Open the Swifter platform URL in a browser and sign in when redirected. Depending on how your organisation is configured, you will either go through SSO (your existing corporate identity provider) or an OAuth flow against your version-control or identity vendor. Either way, identity is delegated — there is no separate Swifter password to manage, and onboarding a new user is a matter of granting them access at the identity-provider level.
After a successful sign-in you land on Home — the projects list scoped to the organisation you belong to. If your account is associated with more than one organisation, the first one is pre-selected and you can switch from the header.
Home and Organisation
Home is the single jumping-off point for everything you can do in the platform. The main pane lists every project in the current organisation as a clickable card; clicking a card takes you straight into that project's Workspace. The header carries two controls worth knowing about from day one — the organisation switcher (only visible when you belong to more than one) and the gear icon that opens organisation Settings.
If the projects list is empty, Home guides you to one of two next actions: Create new project (when integrations are already set up at the organisation level) or Go to Settings → Integrations (when they are not). Which one you see depends on what the organisation admin has already done.
Integrations Pre-requisite
Before any project can be created, the organisation admin must configure at least one integration of each of the three required categories under Settings → Integrations. These connections are owned at the organisation level and reused across every project, which means each new project picks integrations from a list rather than re-entering credentials.
| Category | Examples | What it is used for |
|---|---|---|
| Issue tracking | Azure DevOps Boards, Jira | One-way sync of work items from the tracker into the project backlog. |
| Version control | GitHub, Bitbucket, Azure DevOps Repos | Branches, commits, and pull requests for each work session. |
| Design system | Figma | Design context that frontend agents consume when generating specs and UI. |
If any of the three categories is missing, project creation is blocked and Home surfaces the Go to Settings prompt. The same restriction applies even if the team intends to start from a template — every project has a version-control target, an issue tracker, and a design system attached at creation time.
Roles and Access
Access is identity-driven and split across three practical roles. Org admins own the credentials in Settings → Integrations and set up the analytics Dashboard; project admins create projects, manage modules and the work-item query, and add members on the project's People page; product engineers (the default project role) work inside projects — Reqs, agent chat, App / Dev / Test tabs, and PR actions.
The platform never leaves a project without an admin — the last project admin cannot be removed or demoted until another admin is assigned. When you create a project you are automatically its first project admin; everyone else you add lands as a product engineer until promoted.