Every project has an owner: your organization, not a person
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 metadata; membership determines what a person can do.
- Organization owns team owns project
- Layered RBAC
- Instant session revocation
- Fail-closed deletion
- organization owner · admin · member · viewer
- team lead · member · viewer
- project owned by both
- creator audit metadata only
Organizations own teams, teams own projects
Repository access follows the same rule. See Source Control & Integrations for how provider connections work.
Two role systems, not one admin flag
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 team that owns a project. A platform-wide role (super admin, admin, user, or viewer) sits above both.
Admin, user, and viewer are derived 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 is a ceiling and never expands access beyond your organizations and teams.
Organization roles
- owner
- full authority over the organization
- admin
- manages members, teams, and source connections
- member
- standard access to the organization’s teams and projects
- viewer
- read-only access, no membership or write actions
Team roles
- lead
- manages team membership and project ownership within the team
- member
- standard access to the team’s projects
- viewer
- read-only access to the team’s projects
Permissions such as transferring a project or managing membership are checked against this stack on every request, and the workbench hides write actions your role does not permit while the content stays visible. See Security.
Organization administration without another destination
Organization is a utility over the current destination. It provides General, People, Invitations, Teams, Initiatives, Connections, Services, On-call, and Release hosts, all wired to the tenancy API. From there you create organizations and teams, invite or remove members, and assign organization and team roles.
- offboarding
- Removing a member preserves the projects they created, their source connections and repositories, and their active programs; creator and connection attribution stay intact.
- revocation
- Every membership or role change advances an authorization revision counter, and the instant it changes, that user’s live WebSocket connections, including open preview-log streams, close with an explicit “Authorization revoked” reason. No session outlives the change.
Move a project without losing its history
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.
Cross-organization transfer
- permission
- Gated by its own dedicated permission, from the project’s settings
- fence
- Active preview and delivery state is fenced during the move
- rebind
- Repository authority moves to the destination
- detach
- Organization-scoped links (portfolio items, service-catalog entries) are detached in the same transaction
Fail-closed project tombstones
- states
- Not requested, pending, in progress, failed, completed, enforced by database constraints
- deletion
- An organization or team deletion is blocked while any project it owns is not completed, so nothing is orphaned or race-deleted
- posture
- Refuse-first, the same as CrewWork’s platform-wide safety controls
Group projects and coordinate cleanup 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.
- portfolio
- A two-level hierarchy where initiatives contain epics and only epics link to projects, with live rollups of project-state distribution, health, and action-item counts
- service catalog
- Teams register logical services and link them to active projects, with cross-organization link protection and live unknown/partial/complete readiness scorecards
- campaigns
- Time-boxed, filtered by finding family and severity, with an optional minimum risk level, aggregating action items across every project a team owns, with live resolved/blocked/remaining progress
Compliance evidence, pulled together automatically
Any project member with read access can pull a point-in-time evidence report over a project’s existing records, grouped into PCI DSS-oriented and OWASP ASVS-oriented views the way reviewers look for it.
| Evidence area | Drawn from |
|---|---|
| Policy | Security and quality-gate policy |
| Security scan | The latest security scan |
| Dynamic analysis | Dynamic analysis findings |
| Software inventory | SBOM and VEX records |
| Quality gate | Quality-gate results |
| Release provenance | Release records |
| Deployment observation | Deployment health |
| Audit trail | The project audit trail |
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.
The selected Project’s assurance workspace shows each compliance evidence area’s status, observations, and gaps, alongside the API.
See whether CrewWork fits your work.
CrewWork is built and running, and not yet generally available.
- worth discussing
- The errors and backlog you would hand off
- Where your source has to stay
- The evidence you would need to trust a change