Skip to main content
Everything in Pipefort belongs to an organization: repositories, scans, findings, triage states, and rule settings are shared by the organization’s members. Two things stay personal: your Slack notification settings (your channel, your choice) and your GitLab identity.

​
Personal and team organizations

Every account has a personal organization, created automatically — if you’ve used Pipefort before organizations existed, all your data was migrated into it and nothing changed. To collaborate, create a team organization from the organization switcher in the header (the building icon), then invite teammates. The switcher also selects which organization the whole app operates on — dashboard, repos, Attacker Mind, rule settings, all of it follows the active organization.

​
Roles

RoleCan
memberEverything day-to-day: connect installations, scan, monitor, triage, change rule settings, open fix PRs, view members.
adminAll of the above, plus: invite/remove members, change roles, revoke invites, rename the organization.
The creator of an organization is its first admin. An organization always keeps at least one admin — demoting or removing the last one is refused.

​
Inviting teammates

  1. Open Settings with the team organization active.
  2. In the Organization card, enter the teammate’s email and a role, and click Invite.
  3. No email is sent (v1). When someone signs in to Pipefort with that email address, a banner on the Settings page shows the pending invite with an Accept button. Tell them out-of-band.
Invites match on the sign-in email (case-insensitive). Accepting adds the organization to their switcher; their personal organization is untouched. Admins can revoke pending invites from the same card.

​
Leaving

Members can leave a team organization from the Settings page. You can never leave your personal organization — it’s where your account’s own data lives.

​
How access works

  • One organization = one tenant: each org has its own copy of a repository (its own scans, findings, triage). Two organizations that install the same GitHub App installation scan independently.
  • Monitored repos: a push triggers one scan per organization monitoring the repo, and notifications go to every member of that organization who has them configured.
  • Provider credentials follow whoever connected them: scans of a GitLab repo use the OAuth token of the member who linked GitLab, regardless of who clicks Scan.
  • Row-level security enforces membership all the way down to the database — the browser can only ever read rows of organizations you belong to.