Groups & Projects
Groups and projects are how you organize people and work inside a workspace. Almost every other admin control depends on them: budgets attach to projects, hardware policies apply to groups, and the option to require a project on every job is meaningless until both exist.
Both live under Workspace Admin > Teams, alongside Members and Invite Members.
The chain
Four things link together in a fixed order, and the order is why setup sometimes appears to fail:
Members belong to groups · groups are assigned to projects · budgets attach to projects · jobs run under a project.
Two consequences follow from that chain:
- Create groups before projects. A project's membership is defined by the groups assigned to it, not by picking individuals, so there is nothing to assign until the groups exist.
- A budget on a project only constrains people who can reach that project, which means the group assignment is what makes a project budget bite.
Budgets can also be set directly on a member or on the whole workspace, so projects are not the only route to spend control. See Budgets & Deposits.
Groups
A group is a named collection of workspace members. It is the unit that hardware policies apply to, the unit you assign to a project, and a convenient level to look at cost.
Creating a group and adding members
- Go to Workspace Admin > Teams > Groups.
- Click New Group and give it a name. Names are how the group appears in every other picker, so name it after the team or program rather than the person who created it.
- Open the group and use Add a member to this group to add people by name or email. Search members... filters the list once the group is large.
A member can belong to several groups, and a group can be assigned to several projects.
Group admins
Each row in a group's member table has a Group Admin checkbox. Ticking it delegates management of that group without granting workspace administration, which is the lightest-weight delegation available: a group admin can look after their own team's membership while workspace and organization roles stay with you.
Group billing
A group page also carries a Group Member Billing table, which is the quickest way to see what a team is spending without building a report. It breaks charges out per member, over a month range you choose, with a CSV download per member.
The columns match the ones in billing summaries: core hours, hardware, software, storage, transfer, connections, platform, deposits, applied credits and deposits, and total. As everywhere in billing, the figures are calculated in UTC, so month boundaries are UTC boundaries.
Deleting a group
Delete Group removes the group. Members are not deleted, and their jobs are unaffected. Check where the group is used first: deleting a group that is a project's only collaborating group leaves that project with no one able to create jobs under it.
Projects
A project is a container that ties jobs to a team, a budget, and a set of resource limits. It is also the unit that appears in billing summaries and in job records.
Project settings
Click Update to save. The Max Concurrent Active Cores field is empty when there is no project-level cap.
Collaborating groups
This is the part that catches people out. The platform states the rule plainly:
Members in these groups can create jobs under this project.
Access is granted by group, never by individual. Use Add a group to assign one. A project with no collaborating groups is still valid. It just means only administrators can use it, which is a legitimate setup for a project that exists to hold a budget or to collect reassigned jobs.
Budgets on a project
The project page has its own Create Budget button, which is usually the fastest route to a project budget. The alternative path is Financials > Budgets in either admin portal. Both create the same thing. See creating a budget.
Jobs in a project
Project Jobs lists the jobs already assigned, filterable by ID, name, owner, and status. Assign jobs to this project moves existing jobs into it, which is how you correct work submitted under the wrong project, or bring historical jobs under a project so they appear in its billing.
The list shows each job's lineage, so a job duplicated from another is identifiable.
Deleting a project
Delete Project removes it. Prefer clearing Is Active if the project has history you want to keep in billing reports.
Requiring a project on every job
Workspace Admin > Policies > Platform Settings > General Settings has Require jobs to be assigned to a project. It is the control that makes project budgets enforceable rather than advisory.
With this setting on, a member cannot submit a job until they are in a group, that group is a collaborating group on a project, and the project has a budget. Turning it on before the groups, projects and budgets exist blocks job submission for everyone who is not yet covered, and it presents as a platform fault rather than a policy.
Create the groups, assign them to projects, attach budgets, then enable the setting.
Related
- Organizations & Workspaces — the portal split, inviting members, and delegating workspace and organization administration
- Budgets & Deposits — workspace, project, and member-level spend controls
- Hardware Policies — the policies that apply to groups
- Billing & Reports — billing summaries broken out by project and member
- Running Core Limits — the workspace-wide concurrency cap