Core Concepts
Access Control
CodeCargo provides role-based access control at the organization and project levels, with team management for grouping users and personal access tokens (PATs) for API authentication.
Organization Access
Manage your organization's users and teams from Organization Settings → Access. The access page has two tabs: People and Teams.
People
The People tab lists all users in your CodeCargo organization. Each user has an organization-level role:
| Role | Description |
|---|---|
| Admin | Full organization control, including all projects, teams, CargoWall, and Migration Assistant |
| Architect | Manage all projects, CargoWall, and Migration Assistant, without organization or team administration |
| Member | Basic organization membership with view access |
Organization Admins can update user roles from the actions menu on each row.
Organization Owners
"Organization Owner" is not a CodeCargo role — it refers to GitHub organization owners, who automatically receive full access to every CodeCargo project (shown as the "Org Owner" access source on project access lists).
Teams
Teams let you group organization members for easier project access management. Instead of granting access user by user, assign a team to a project and all team members receive the same role.
Click a team name to view its detail page, which lists all current members with their GitHub avatars and names.
GitHub Team Sync
Team membership in CodeCargo reflects your GitHub organization's team structure. Changes to GitHub team membership are synced automatically.
Project Access
Each project has its own Access page where you control who can view and manage project resources. Navigate to a project and click Access in the sidebar.
Project Roles
| Role | Description |
|---|---|
| Admin | Full access to project resources and settings |
| Editor | Can manage Self-Service Workflows and project content |
| Viewer | Read-only access to project resources |
Granting Access
Click Grant to add a user or team to the project. Select whether you are adding a user or a team, choose the member, and assign a role.
Access Sources
Project access can come from multiple sources. The access list shows the origin of each entry:
| Source | Description | Editable? |
|---|---|---|
| Explicit | Manually granted in CodeCargo | Yes |
| Org Owner | User is an organization owner (automatic full access) | No |
| Org Default | Inherited from the organization-level default role | No |
| User Default | User's personal default project role | No |
| Team Default | Team's default project role | No |
| Repo Access | Granted via GitHub repository permissions | No |
Organizations, teams, and users can each have a default project role that is applied automatically, which is the origin of the Org Default, Team Default, and User Default sources.
Only Explicit access entries can be updated or removed. Non-explicit entries can be "upgraded" — granting explicit access replaces the implicit entry.
Organization Owners automatically have access to all projects and cannot be downgraded.
Team Org-Level Roles
Teams with organization-level Admin or Architect roles automatically receive Admin access to all projects in the organization. This inherited access appears in the project access list as access granted through the team rather than as an individual entry.
Team Role Inheritance
When a team has an org-level Admin or Architect role, all projects automatically grant that team Admin access. Team members inherit this access through their team membership, and explicit project access cannot be downgraded below this inherited level.
Key behaviors:
- Teams with Admin or Architect org roles get automatic Admin project access
- This inherited access cannot be downgraded to Editor or Viewer roles
- Team members appear in project access through their team, not as individual entries
- Explicit team access can only maintain or upgrade the inherited role level
Migration Assistant Access
Migration Assistant operations require the MigrationAssistantManage permission, which is granted to teams with organization-level Admin or Architect roles. This allows migration work to be performed without requiring GitHub organization owner privileges.
Permission Scope:
- Create, update, and delete migration entities and batches
- Configure migration mappings and repository associations
- Import legacy CI/CD data and manage migration workflows
- Launch migrations via "Migrate in Editor" to open the GenAI Editor for AI-assisted conversion
Role Access:
- Org-level Admin and Architect roles: Full Migration Assistant management capabilities
- Member (org role): Read-only access to view migration data and progress
This permission model enables platform architects and migration specialists to manage large-scale CI/CD migrations without requiring the elevated privileges typically associated with organization administration.
Migration Permissions
The MigrationAssistantManage permission is separate from general organization administration, allowing you to delegate migration responsibilities to team members who specialize in CI/CD platform transitions.
Personal Access Tokens
Personal Access Tokens (PATs) allow you to authenticate with the CodeCargo API programmatically. Manage your tokens from Profile → Personal Access Tokens.
Creating a Token
- Click Create Access Token
- Optionally set an expiration date — leave empty for a token that never expires
- Click Create
- Copy the token immediately — it will not be shown again
Token Status
| Status | Description |
|---|---|
| Active | Token is valid and can be used for API calls |
| Expired | Token has passed its expiration date |
| Never Used | Token has been created but never used |
Managing Tokens
From the actions menu on each token you can:
- Edit — update the expiration date
- Delete — permanently revoke the token (requires confirmation)
The token list shows each token's short ID, status, last used timestamp, and expiration date.
GitHub Permissions Integration
CodeCargo's access model integrates with GitHub in several ways:
- Repository Access: Users who have access to a GitHub repository linked to a project automatically gain project access (shown as "Repo Access" source)
- Organization Owners: GitHub organization owners receive automatic full access to all CodeCargo projects
- Team Sync: CodeCargo team membership is synced from your GitHub organization's team structure
- Explicit Overrides: You can always grant explicit CodeCargo access that supplements or overrides GitHub-based permissions
Permission Hierarchy
Explicit CodeCargo permissions take precedence over GitHub-inherited permissions. When you explicitly grant access, the implicit entry is replaced. This lets you upgrade a user from viewer (via repo access) to editor or admin as needed.
Support Access
Support Levels
Support options vary by plan. Starter plans include community support, Team plans include dedicated Slack support, and Enterprise plans include dedicated enterprise support. See pricing for details.
Organization administrators can enable support access to allow CodeCargo support team members to access your organization for troubleshooting and assistance. This feature is disabled by default and requires explicit opt-in.
To enable support access:
- Navigate to Organization Settings → Advanced
- Toggle Allow Support Access to enable
- Confirm the change
When support access is enabled:
- CodeCargo support team members can be granted temporary access to your organization
- Support users can view organization resources but cannot make changes without explicit permission
- Support access is managed through administrative commands and requires organization opt-in
- Organizations that haven't enabled support access remain completely inaccessible to support users
Privacy and Security
Support access is strictly opt-in. Organizations that don't enable this feature cannot be accessed by CodeCargo support team members under any circumstances. Support users also don't have GitHub tokens, so they cannot trigger repository synchronization or perform GitHub operations.
Repository Access Validation
CodeCargo continuously validates your access to repositories during operations like changeset management. If your permissions to a repository are removed while you're working with it (for example, if you're removed from a team that had access), you'll see a security-conscious error message:
"Repository is not available"
This message protects against information disclosure while letting you know that the repository can no longer be accessed. Repository access is re-validated each time you perform operations to ensure you only work with repositories you currently have permission to access.
Permission Changes
If you lose access to a repository during an active session, any in-progress operations involving that repository will fail with an access error. Contact your organization administrator if you believe you should have access to a specific repository.
