Verify onboarding before expanding team access

Learning objective

Plan team rollout with access groups, spend controls, and usage visibility, and verify onboarding reproducibility and configuration drift.

Core idea

A rollout succeeds when an intended member can perform an approved workflow, the organization can explain its cost, and the effective configuration matches the approved release. Seat assignment, a successful sign-in, or a populated dashboard proves only part of that outcome.

Treat onboarding as an acceptance check with named owners. Identity administrators own membership; finance owns spending authority; developer-tools owners own the configuration and supported environment; the observability owner verifies delivery into reporting. Define what must pass before the next cohort receives access and what failure suspends expansion.

How it works

Choose the access route before designing the reports

Claude Code billing and reporting depend on how the developer authenticates. Match controls to that route:

For Teams and Enterprise, usage inside the seat allowance is not metered in dollars. The spend report covers usage-credit spend and appears when usage credits are enabled. A low dollar total therefore does not prove low adoption, and a group spend limit does not price the seat allowance itself.

On Console, Claude Code authentication creates a dedicated Claude Code workspace that centralizes that usage. It is not a workspace in which you can create API keys. Distinguish that managed authentication route from separately supplied API credentials when planning attribution.

Anthropic’s Claude Code dashboards and Analytics API do not cover usage on those third-party cloud providers. Choose provider or gateway reporting for that population. A budget notification is also different from a preventive spending limit: verify the provider’s actual enforcement before promising finance that work stops at a threshold.

Provision deliberate cohorts and remove access deliberately

The Enterprise administrator guide describes single sign-on (SSO), System for Cross-domain Identity Management (SCIM) provisioning, and phased expansion of identity-provider groups. SCIM synchronizes users from the identity provider; just-in-time provisioning creates them at first SSO login. For a tightly bounded pilot, manual invitations can also be appropriate.

Record which identity group receives access and which owner approves its expansion. Choose a small representative cohort with the operating systems, repositories, and authentication methods the wider rollout will use. Do not define the pilot solely as the most experienced developers if the onboarding requirement includes people without their local tools and credentials.

Separate access groups from configuration targeting. A group can receive a seat or spending allocation without receiving a distinct server-managed policy: those settings apply uniformly to an organization. Use the targeted delivery choices in 7.1.4 for pilot configuration changes. For offboarding, have the identity owner verify membership removal and the integration owner handle credentials separately; removing one membership is not a claim that every external service token was revoked.

A managed forceLoginOrgUUID restricts claude.ai account logins to the named organization or organizations. A non-managed single UUID only pre-selects an organization and does not enforce that membership restriction. Use the managed form when organization identity is mandatory, and verify the active authentication method rather than accepting an account picker as proof.

Make onboarding a repeatable acceptance record

Give each cohort the approved repository revision, supported Claude Code version, intended authentication route, and expected integrations. Have a participant with a clean environment complete a representative task instead of asking them to confirm that installation instructions looked reasonable.

Capture the following observations in the onboarding record:

• /status: the intended sign-in method and managed Setting sources are present.
• claude doctor: no rejected configuration entries undermine the approved setup.
• /permissions: the effective rules have the intended source files, without accidental broad personal grants.
• /mcp: the required integration connects under the participant’s authorized identity.
• A representative task: the shared procedure completes its useful work, and a harmless prohibited-action probe is rejected.

These observations complement the shared-file review in 7.1.1. A working connection does not prove that the right endpoint or access scope was selected, and a settings file does not prove that its executable dependencies exist. Record failures by stage so the identity, integration, or tools owner can repair the correct layer.

Use managed requiredMinimumVersion when the approved configuration depends on a version floor. It refuses startup below that floor; the check runs at startup, so an already-running session continues. The key requires Claude Code v2.1.163 or later. Select the floor from the mechanisms you actually deploy, such as the version needed for policy-digest telemetry, rather than copying an arbitrary example version.

Detect effective-policy drift as well as file drift

Comparing repository revisions detects shared-file changes. Comparing /status across machines detects different managed-source selection, including Skipped sources on supported versions. Neither proves the resolved managed values are identical.

For fleet verification, Claude Code v2.1.274 or later emits claude_code.managed_settings_resolved at startup and when the managed settings or policy-helper state changes. It reports sources and source behavior by default. With OTEL_LOG_MANAGED_SETTINGS=1, it adds redacted settings and managed_settings.resolved_sha256, a digest of the resolved managed settings before redaction. Equal digests establish equal managed policy; they do not establish equal personal settings, repository contents, or external permissions.

Configure OpenTelemetry with CLAUDE_CODE_ENABLE_TELEMETRY=1, exporter selectors such as OTEL_METRICS_EXPORTER=otlp and OTEL_LOGS_EXPORTER=otlp, and the approved OTEL_EXPORTER_OTLP_ENDPOINT. Put exporter configuration in managed settings, user settings, or the launch environment. Repository settings cannot turn it on or choose the destination. Verify collector receipt; a configured endpoint is not a received event.

The policy-digest opt-in deserves an explicit data decision. Although settings values are redacted in the accompanying payload, a short policy can be guessed by hashing candidate policies, which is why the digest is opt-in. Restrict access to this operational record and keep its purpose focused on drift diagnosis.

Key distinctions and trade-offs

Access versus policy: Group membership determines who enters the rollout. Managed-source delivery determines which configuration their session enforces.

Adoption versus spending: Active use and estimated usage-credit cost have different denominators. Neither should stand in for successful approved tasks.

Identical managed policy versus identical environment: A matching digest narrows a drift investigation. It does not prove that developer dependencies, credentials, or repository revisions match.

Architecture / decision scenario

An education provider plans to expand from 12 to 120 engineers with a two-week pilot and a proposed $2,400 monthly usage-credit ceiling. All 12 pilots sign in, but only 7 complete the standard onboarding task; 3 lack an integration credential and 2 select an unexpected managed source. Finance sees little spending and proposes immediate expansion.

The rollout owner holds expansion because sign-in and low spending do not meet the task-completion criterion. Identity administrators maintain the pilot group, finance applies the agreed organization and group usage-credit limits, and the integration owner repairs the three credential paths. Developer tools fixes source selection, confirms the policy digests and repository revisions, then repeats onboarding from clean environments. The team expands only when the useful task and rejected-action probe pass, with adoption and spend reported separately.

Common exam traps

• Treating seat assignment or successful sign-in as completed onboarding.
• Treating usage-credit spending as the dollar value of all seat usage.
• Expecting Anthropic dashboards to include third-party cloud usage.
• Expecting a repository to configure the fleet’s telemetry exporter.
• Treating equal policy digests as proof of identical complete environments.
• Expanding a pilot because costs are low while authorized work still fails.

What to remember

Choose access, spending controls, and reports for the actual authentication route. Verify onboarding through effective policy, working integrations, and task outcomes. Detect drift across repository revisions, managed sources, and resolved policy before adding the next cohort.

Knowledge check

References

• Anthropic, Claude Enterprise Administrator Guide
• Anthropic, Manage costs effectively
• Anthropic, Monitoring
• Anthropic, Settings reference
• Anthropic, Deploy managed settings
• Anthropic, Configure permissions
• Anthropic, Connect Claude Code to tools via MCP