Members & roles
Think of X4RGE access in two steps: first someone joins your company on the platform, then you add them to each project they should work in.
Organization membership is the company badge — it lets them sign in and belong to your org. Project membership is the key to a specific initiative — which repos, tasks, views, and agent runs they can see. Without both (where your org requires it), a person may be in X4RGE but still not see the project you expect.
This page explains project-level people and permissions. To invite someone to the company, use Dashboard members. For org-wide rules and models, see Settings and Model control.
What this page is for
Org role (Members) — Can they use X4RGE at our company? Project role (this page) — Which projects, repos, and tasks can they see? Most day-to-day contributors need org member + project member on the right projects — not org admin.
Understand members and roles at a glance
Typical onboarding path:
- Invite to org (Dashboard → Members)
- They become an org member (can sign in)
- Add to project (Project → Members)
- Choose project member (contributor) or project admin (lead / tech owner)
- Optionally set project lead on the overview
- Project admin links GitHub when repos are ready
Most teams stop at step 4 for engineers — only leads need project admin.
Org vs project membership
If Require project assignment is on in Settings, org members cannot run agents until they belong to at least one project — even if they can sign in.
Choose the right role
Use this when adding or updating someone:
Rule of thumb: give the smallest role that lets them do their job. Org admin is for people who manage billing, company settings, and every project — not for every engineer.
If someone needs to create tasks, run agents, and use linked repos, project member is usually correct. Choose project admin only when they must add teammates or connect GitHub.
Why project membership matters
How membership fits together
Typical flow: invite to org → add to project → assign role → optionally set lead → link repo (project admin).
In practice
Organization roles
These apply company-wide on X4RGE:
Org admins are your escalation path when a project admin is out or access is blocked.
Project roles
These apply inside one project:
*Subject to org and project model policy. **Some companies limit shared views to leads and admins.
Project admins cannot change company billing, the global model catalog, or contract settings — those stay on the dashboard.
Project lead vs project admin
These are easy to confuse. Here is the difference:
You can make someone lead without project admin if they only need visibility and escalations, not repo or membership changes. In practice, leads who run the project day-to-day are usually project admins too.
Add members
Open Members
In the Projects app, open your project → Members. You need project admin or org admin / super admin.
Add from your organization
Search by name or email. They must already be an org member — use Dashboard → Members to invite them first if not.
Choose a project role
Project member for contributors. Project admin for whoever manages repos and membership. Optional labels (e.g. "Backend") help filtering in large projects.
Confirm they can work
They should see tasks, views, and repos immediately. If agents are required, confirm they're on at least one project when your org uses Require project assignment.
Project lead
Designate a lead
From Members, pick project lead. One name appears on the project overview for accountability and escalations.
Transfer lead
When ownership changes, assign the new lead before removing the old lead from the project if they should lose access entirely.
Remove access
Remove from project only
Project admin removes them from Members. They stay an org member but lose this project's tasks and repos — use this when someone moves to another squad but stays at the company.
Remove from organization
Org admin removes them from Dashboard → Members. All project access ends immediately — use when someone leaves the company.
If security is a concern
Ask an org admin to revoke active sessions from Settings as well as removing membership.
Removal is immediate. Reassign open tasks and in-flight agent runs first.
Fix access issues
When someone says they can't see a project or can't run agents, check in order:
Org membership
Have they accepted the org invite? Pending invites cannot access projects. Org admin checks Dashboard → Members.
Project membership
Are they on this project's Members list? Org members are not auto-added to every project — a project admin must add them.
Project assignment gate
If agents fail but the project is visible, check Require project assignment in Settings. The person needs membership on at least one project.
Repo and integration
If work involves GitHub, confirm repos are linked and the person is allowed to use agents on this project — see GitHub integration and Troubleshooting.
Escalate to org admin
Org admins see all projects and can add members, fix integrations, and adjust org-wide policy.
Teams and projects
Teams (Settings → Teams) group people at the company level. A team may link to projects for budgeting and model rules when you manage many squads.
Someone gets access to a project through:
- Direct project membership — most common; use the steps above, or
- Team link — when your org connects a team to a project (setup varies).
Project rules can be stricter than team or org defaults — never wider. If access seems wrong after a team change, ask your org admin which layer applies.
Team roles (admin, member, viewer on a team) are separate from project roles (project admin, member on a project). Match both to how your company is organized — don't assume they're the same.