An organization is the top-level container above teams: one place where shared identity, administration and company-wide settings are defined. Teams remain self-contained units: each keeps its own membership, roles, usage views, privacy settings and controls. The organization does not replace the team, it takes away what should not be decided inside a department: login, the employee directory, the contract and the rules common to everyone.
The naive picture is natural because the structure grows from below. First there is one team, then a second, then a separate team for contractors, and each sets up its own login, its own list of people and its own limits. While there are two or three teams this is cheaper than any centralization: the setup takes half an hour, there is nobody to agree it with, and the difference between teams looks like useful flexibility rather than divergence.
It breaks on arithmetic. There is not one setting but a dozen, and every new team multiplies them; a person belongs to several teams at once and holds a different role in each, while being absent from another; a departure has to be closed in three places, and forgetting one is enough; spend is counted per team although the contract is single. None of these looks like an incident on its own, and together they produce a state nobody can describe as a whole.
The professional mechanism starts with configuring login once at the top instead of repeating it in every team. An organization has a default team - a stable home for login and routing. Org-level single sign-on with your identity provider is the recommended way to log in at company scale, while team-level login stays supported for cases with their own identity requirements. Account provisioning at the organization level makes directory groups visible to the system, and an admin chooses which of them to sync. An organization can draw on several directories if the joined teams had different providers; consolidating them is possible, but settings are locked while the merge runs and the operation cannot be reversed.
The second pillar is organization groups - cohorts that cut across teams: engineers, contractors, pilot users. A synced group mirrors the directory, its membership is read-only in the console and changes at the identity provider. A manual group is maintained by an admin through the console, a list import or the organization API, and can later be connected to a directory group. A group mapped to a team governs that team's roster entirely: joining the group adds the person to the team, leaving removes them unless another mapped group still covers them, and manual editing of membership on such a team is disabled. Groups are created and maintained by organization admins; a team admin cannot do it.
From here grows the main operational question. The same value can be set on four layers: the team, the person on the team, the directory group and the organization group. The general conflict rule has to be known by heart: the more permissive wins. It has one important exception - a per-user value on a team member beats both team defaults and directory group settings. Below is that map: the setting, the merge rule and the consequence that makes the rule worth remembering.
The rule unfolds differently for different settings. A spend limit takes the highest applicable value. Model access is a union: a model is available if the team or any group allows it. Auto-run controls merge field by field, and in each field the looser value wins, so a disabled sandbox beats an enabled one. Auto-review instructions do not merge but replace: group instructions supersede team ones for the affected people. Team roles do not participate in merging at all, they are determined by group-to-team mappings. The practical consequence is single: a forgotten broad group lifts the restriction for everyone inside it, and the team settings screen does not show it.
| Setting | Merge rule | Consequence |
|---|---|---|
| Spend limit | The highest applicable value wins | A broad group raises the ceiling for everyone inside it |
| Model access | Union: permission from the team or any group is enough | A ban holds only if every layer bans it |
| Auto-run controls | Field-by-field merge, the looser value wins in each field | A disabled sandbox in one group cancels an enabled one |
| Auto-review instructions | Group instructions replace team instructions | For the affected people the team text does not apply |
| Team roles | Determined by group-to-team mappings | No merging, manual roster editing is disabled |
| Team roster | The union of the rosters of all mapped groups | Leaving one group does not remove from the team if a second covers it |
| Spend and reporting | Counted per team, funds drawn from the shared pool | Billing groups set attribution, not restriction |
The second half of the problem is solved by a shared budget. Instead of a fixed share per person the organization gets a single pool for the contract period, drawn on by whoever needs it most; an unspent share of a quiet month does not burn with one person but goes to another working through a heavy task. Usage is tracked cumulatively across the contract term rather than reset every month. Control does not disappear: spend alerts on configurable thresholds reach admins by email, and team-wide limits can scale as the roster grows and shrinks, and only an admin may change these settings. Day-to-day reporting is collected per team, while billing groups are a separate thing: they decide whose spend it is, not what a person is allowed to do.
The price of the top layer is irreversibility and non-obviousness. Consolidating identity providers cannot be replayed backwards, and a person's effective setting stops being readable from a single screen: it is composed of the team, the personal value and every group they belong to. The layer is justified where there are more than two teams, one directory and a common contract; for a single team it adds work and gives nothing back. The result is verified by behavior rather than by the settings screen: create a person in the directory and see which teams they appeared in; remove them from a group and confirm they actually left the team; give one person membership in two groups with different limits and see which limit applies - the higher one should remain, not the one set last.
The typical failures are predictable. Assuming a team setting overrides a group setting. Leaving the pilot group broad permissions after the pilot ends. Consolidating identity providers without writing down in advance what is lost. Mapping several groups onto one team and being surprised that the roster is their union. Mistaking a billing group for a restriction tool. And moving the company to a shared budget without setting alert thresholds, then learning about the spend from the invoice.