Cursor Organization Groups: Cross-Team Cohorts for Admins

Organization Groups gather people from different teams into one cohort when the same set of users needs shared settings. Cursor names Engineering, Contractors, Executives and Pilot Users as examples. They are separate from Billing Groups: Billing Groups help a team report and attribute spend, while Organization Groups manage organization-level cohorts and the settings that apply to them.

An Enterprise org can have three group concepts live at once. Billing groups attribute spend inside one team, SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition. directory groups carry team-level spend and policy from your identity provider, and Organization Groups sit above both. The difference that bites is membership shape: a member sits in exactly one billing group at a time, while a user can belong to several Organization Groups, which is why Cursor publishes a rule for combining what those groups say.

Groups live at the Organization level rather than in team settings. Open Organization from your profile menu, then Groups in the left sidebar. Cursor supports two kinds, and the choice sets where membership is owned from that point on.

Make that choice before you add anybody. Membership in a synced group is owned by your identity provider, and Cursor disables the manual edits the next sync would overwrite, so a list you curate in the dashboard stops being the thing that decides who is in the group. In a ten-person org where the same person administers Okta, that is a short conversation. In a large one, creating or extending a directory group probably lands in a queue you do not control, so open that request before you promise anyone a date.

The standard identity advice, sync every group from the directory, is the one I would break for a pilot. Cursor points SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition. at groups that already mirror a department, role or access cohort, and a pilot cohort is defined by who wants in this week. Keep that one manual, in the dashboard or through the Organization API, and let the directory own the long-lived ones.

Open a group and select Members to view and manage membership. What you can do depends on whether the group is manual or SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition.-synced.

• Manual groups: add existing Organization members, import members by CSV, move members to another group, remove members, and search and sort the list.
• SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition.-synced groups: membership is read-only, but admins can still manage Cursor-owned settings such as spend limits and model access.

Nothing on that list provisions a person.

A manual group draws from members who are already in the Organization, so it is a view over people who exist rather than a way to onboard new ones. When somebody you expect to find is missing from the picker, rule out the upstream cause before you touch the group. Cursor's SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition. doc notes that a provisioned account stays off the Members dashboard until that person signs in for the first time.

Open a group and select Settings to manage group-level controls. Cursor documents three: per-user spend limits, model access on the Models tab, and group-level agent and model-routing controls. Spend limits and model access combine with team settings using a permissive model, so the intended shape is strict defaults at the team level and wider access for chosen cohorts on top.

The order in that recommendation is load-bearing. Widening is the only direction a group can move those two, so the strictness has to exist at the team level before a group has anything to carve an exception out of. Build it the other way round, with generous team defaults and a Contractors group meant to hold the line, and the group changes nothing at all. I used to describe a group as the place a cohort's policy lives. That is the wrong way round. Policy sits at the team level, because that is where a setting can be strict, and a group is where you record the exceptions.

Unwinding that costs more than editing a group. The fix is to tighten the team default, which lands on everybody in that team, including the people who were never the reason for it.

Cursor lists auto-run and Smart Auto as group-level controls 'where available', and that qualifier is the doc's rather than mine, so confirm both in your own dashboard before you plan a rollout on them. The same settings page carries the Cyber Safeguards Models Settings section, where an admin applies for Anthropic's Cyber Verification Program, and Cursor takes that application only at the Organization Group level. A single-team org that wants it still has to create a group.

Because you are most likely in a team directory group or a billing group instead of an Organization Group. Cursor's answer is to open Organization → Groups from your profile menu and click into a specific group, where the group-only settings appear. Cursor carries the same question in its Cyber Safeguards FAQ, where the section people cannot find is Cyber Safeguards Models Settings.

When a group setting looks like it is being ignored, membership is the first thing to check. Pull the list of groups that user belongs to: a second group can be supplying the value that wins, and a synced group holds exactly who the last sync said it holds. Their team is the next place to look, since a team-level block still reaches them.

For a synced group, look upstream of Cursor first. Group push provisioning has to be enabled in the identity provider separately from user provisioning, and SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition. needs an active SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. Press Enter for the full definition. connection, so missing SCIM controls point at SSO rather than at the group. On the API side, confirm the key is an Organization key and the id carries the g_ prefix before you suspect the group config.

SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition. lets your identity provider decide who belongs to a group, which Cursor recommends when the group mirrors an existing department, role, or access cohort. Before mapping SCIM groups, make sure SCIM provisioning is configured for your Organization, then connect the Organization Group to the matching directory group.

Handing membership to the identity provider pays off when the cohort already exists there and somebody else maintains it. You inherit their joiners and leavers process, which is the part a dashboard list never really covers. What it costs is the small stuff: adding one contractor for one afternoon means a change in the IdP, because the member list in Cursor is read-only and stays that way.