Background

Standalone CircleCI organizations already have the concept of "Groups" in Organization Settings (https://app.circleci.com/settings/organization/<org-slug>/groups/<group-id>). Today, however, there's no way to scope project access to specific Groups. The ability to restrict projects by Group within an organization would simplify management greatly. This should be a many-to-many relationship: a single project can be assigned to multiple Groups, and a single Group can be assigned to multiple projects.

What's the value add?

Being able to assign projects to one or more Groups gives organizations fine-grained access control over who can see and act on which projects. Because the relationship is many-to-many, teams can model real-world access patterns without duplication (for example, a shared orb project or a centralized config repository can be exposed to several Groups at once). This makes onboarding and ongoing management significantly easier, since access is defined at the Group level rather than project by project.

How would this let customers manage orgs efficiently?

For enterprise organizations with a large number of projects and teams, manual per-project permission management doesn't scale. Group-based restrictions let teams inherit the right access automatically. This becomes especially powerful when Groups are mapped to an existing SSO group, so access can be governed by the customer's existing identity provider rather than managed separately in CircleCI, keeping permissions consistent and reducing the chance of drift. Exposing this configuration through the Terraform provider would make it fully manageable as code, so large organizations can provision, audit, and update project/Group assignments alongside the rest of their infrastructure rather than clicking through the UI.