Loading...
Organizations & Teams
CrewWork is a multi-tenant platform. Every project is owned by an organization and a team, never by whichever individual happened to create it. The creator is kept only as audit-only metadata: membership in the organization and team that own a project is what actually determines what a person can do with it.
Ownership
A project record cannot exist without both an owning organization and an owning team. The database enforces it, and authorization checks read membership, never the historical creator field.
Source control credentials work the same way. Each organization holds at most one active connection per provider (GitHub, GitLab.com, Bitbucket Cloud, or Jira Cloud for issue sync), so repository access belongs to the organization rather than to whoever originally authorized it. See Source Control & Integrations for how those provider connections work.
Access Control
CrewWork replaced a single binary admin flag with layered role-based access control. An organization role governs organization-wide actions such as inviting members, creating teams, and managing source connections. A team role governs what a person can do inside the specific team that owns a project. A platform-wide role (super admin, admin, user, or viewer) sits above both. Admin, user, and viewer are derived automatically from your GitHub repository permissions; super admin is granted only through an operator-configured allowlist. Platform administrators hold a deliberate, auditable platform-wide view. For everyone else, the platform role acts as a ceiling and never expands access beyond the organizations and teams you belong to.
Fine-grained permissions, such as the ability to transfer a project or manage organization membership, are checked against this role stack on every request, and the workbench mirrors that boundary: when your role does not permit a write, the button for it does not render, while the content itself stays fully visible. For how this fits into CrewWork’s broader protections, see Security.
Live Today
The workbench gives tenancy a dedicated top-level Organization surface: an Overview alongside the initiative and epic portfolio, the service catalog, and on-call rotations and escalation routes. People, teams, invitations, and provider connections are managed from organization administration settings, and the whole surface is fully wired to the tenancy API. From there you create organizations and teams, invite or remove members, and assign organization and team roles. The model stays plain: projects are owned by exactly one team.
Removing a member preserves the projects they created, their source connections and repositories, and their active programs. Creator attribution and connection attribution both stay intact after the person is gone.
Every membership or role change advances an authorization revision counter on the affected user. Every backend replica rechecks that counter, and the instant it changes, that user’s live WebSocket connections, both the main session and any open preview-log stream, are closed with an explicit “Authorization revoked” reason. There is no window where a removed member’s already-open session keeps working until a token happens to expire.
Reorganizing
Teams get reorganized, so CrewWork treats that as a first-class operation rather than a manual database edit. Deletion gets the same care in the other direction: an organization or team can only be removed once every project it owns has finished cleanup, never mid-flight.
A dedicated transfer path, gated by its own transfer permission and reachable from the project’s Setup tab, moves a project to a different team or organization. It fences any active preview or delivery state during the move, rebinds repository authority to the destination, and transactionally detaches organization-scoped links (portfolio items, service-catalog entries) so nothing is left dangling across the tenant boundary.
Every project deletion runs through a tracked cleanup state machine (not requested, pending, in progress, failed, completed), enforced by database constraints. An organization or team deletion is blocked outright if any project it owns is not yet in a completed tombstone state, so a reorganization can never silently orphan or race-delete an in-progress project. It’s the same refuse-first posture behind CrewWork’s platform-wide safety controls.
Organize At Scale
Beyond individual projects, organization-owned structures group and coordinate work at scale, computed live from existing project data and available through the organization API.
Governance
Any project member with read access can pull a point-in-time evidence report over a project’s existing records: security and quality-gate policy, the latest security scan and its findings, SBOM and VEX records, quality-gate results, release provenance, deployment health, and the project audit trail. Two views group that evidence the way PCI DSS and OWASP ASVS reviewers look for it.
This is an evidence inventory, not a certification: CrewWork does not determine your compliance scope or issue an attestation on your behalf. It saves the assembly work of gathering what your reviewers will ask for.
A dedicated Compliance evidence panel in the workbench’s Quality & Security surface shows each evidence area’s status, observations, and gaps per project, alongside the API.
See exactly how CrewWork keeps a model honest, explore the architecture, or reach out to talk it through.
Or view the architecture for the full technical picture.