Learn/Claude Academy: Learn the productsguide

Deploying Claude Enterprise with confidence

The five organisation-wide decisions that shape an Enterprise rollout.

claude-academyclaude-enterpriseadminrollout
Series Claude Academy: Learn the products Part 7 of 7
  1. Claude Code in action
  2. Introduction to Model Context Protocol
  3. Model Context Protocol: Advanced topics
  4. Introduction to subagents
  5. Introduction to agent skills
  6. The AI-native SDLC playbook
  7. Deploying Claude Enterprise with confidence

A walkthrough of the Claude Academy course Deploying Claude Enterprise with confidence (Learn the products track, 14 lessons, about 2.5 hours, certificate quiz). Each lesson is summarised with my own tables and examples; take the course for the full lessons. All the courses are listed in the Claude Academy course index.

Note: My own summary of the course, not the course itself; verify details against the lessons and current docs.

Audience / prerequisites: Admins leading or assisting a Claude Enterprise rollout, specifically the Owner, because the five decisions are organization-wide settings. No prior Claude admin experience is assumed. The course teaches judgment, not mechanics: each lesson links to help-center articles for the step-by-step setup.

Running example: Pluto, a fictional fintech with five business units: Retail, B2B, Payments & Trust (regulated), Platform, and Ops.

Work-along companion: A Word or PDF rollout plan with one section per lesson. You fill it in as you go, and it becomes the plan you walk stakeholders through at kickoff.

Module 1 — The plan

Lesson 1: Five decisions and the frame

The five decisions. Make them in this order, because each one scopes the ones after it:

# Decision Question Lessons
1 Structure & Identity How many organizations, and which groups live in them? 4–5
2 Access Which surfaces and connectors does each group get? 6–7
3 Governance Who can build and share customizations, and how freely? 8
4 Spend Where do caps sit, and who owns escalation? 9–10
5 Visibility What can you measure, and how long is data kept? 11–12

Four settings that are hard to undo:

  • Domain claiming (L3): irreversible.
  • Organization topology (L4): a merge or split means re-provisioning every affected member.
  • Group structure / IdP→role mapping (L5): a change shifts access for everyone the mapping covers.
  • Data retention (L11): you can change the window, but content already deleted is gone for good.

The decision frame (used in Lessons 4–11):

  1. Your decision: what you’re deciding, in a sentence or two.
  2. The choices you can make: the options, and what points you toward one over another.
  3. If you change this later: the cost of reversing the decision, for admins and for members.

Rollout objective = what success looks like + the constraints that must hold. Set one company-wide ambition. Unit-level nuance comes in later through phasing and measurement audiences, not through per-unit goals.

  • Pluto: “Every one of the five units uses Claude in daily work by the end of the quarter (measured as weekly active usage per unit), without a single security escalation from Payments & Trust.” When speed and the constraint conflict, Pluto takes the slower path.

Lesson 2: Owners and intake

  • A decision with no owner is one of the quickest ways a rollout stalls. Pick owners by what the role is accountable for and can commit, not by job title.
  • Two decisions usually escalate beyond the Owner: Spend goes to whoever commits the budget, and Visibility goes to whoever answers for data risk.
Decision Look for Pluto’s owner
Structure & Identity Owner + IdP team (Okta, Entra ID, Google Workspace) / IT ops IT lead (holds Owner role)
Access Owner + team leads/champions + data-risk sign-off IT lead; risk lead co-signs write connector grants
Governance Owner + change mgmt/enablement (AI CoE) + security AI CoE lead (IT lead holds the settings)
Spend Owner + budget holder (finance partner/exec) CFO’s delegate
Visibility Owner + security/legal/compliance Risk lead for Payments & Trust
  • The intake questionnaire covers company shape, directory, regulated work, and mandate. It flags which decisions need extra attention at your company.

Lesson 3: Prerequisites

Where you work:

  • Organization settings: groups/roles, connectors, governance, spend, and visibility. Go here to change what a group can do.
  • Identity provider (IdP): group definitions and membership. Go here to change who is in a group.
  • Claude Console: API keys and developer access. It is a separate organization with its own admin model.
  • (Claude Code managed settings belong to the platform lead; see L6.)

Roles: Primary Owner, Owner, Admin, User, plus custom roles. Every action in settings is gated by role. Keep the Primary Owner out of day-to-day admin work, and give each admin the least-powerful role that covers their job.

Six prerequisites before choosing a group structure:

Prerequisite Must-do?
≥2 members hold Owner directly, not via a group (or are already in the IdP group mapped to Owner before you save the mapping) Yes. This is your lockout insurance; do it before SSO
Domain verified Yes. It blocks SSO and group setup
IdP connection configured + SSO enforced Yes. It blocks group sync
Provisioning app set up in the IdP Yes. Without it, groups don’t push
Naming convention for Claude groups No (can run in parallel; renaming later only needs a resync)
Billing owner identified No (not needed until Spend, L9–10)
  • With IdP role mappings on, a direct Owner assignment alone won’t restore access. Only the Primary Owner (never auto-removed) can.

Domain claiming (optional, irreversible):

  • Verifying a domain proves you own it. Claiming moves existing personal accounts on the domain into your org, and new sign-ups go straight to SSO.
  • Requirements: the domain is verified, “Restrict organization creation” is on, SSO is enforced, and provisioning is live.
    • Turn on “Restrict organization creation” even if you never claim. It blocks new personal and Console orgs on the domain.
  • Members get a 30-day migration window. Each one chooses to bring their conversations and projects or to start fresh; if they don’t choose, they start fresh by default.
    • HIPAA readiness or customer-managed keys mean start-fresh is the only option.
    • Custom skills don’t transfer: members must export them first.
    • Connected apps are revoked and must be reconnected.
    • The personal account is always deactivated.
  • Anyone on the domain who isn’t in the IdP is locked out when the claim starts. Add them to the IdP first.
  • Forewarn members. The template covers what’s happening, the choice to make, the transition details, what to expect (reminders), and who to contact.
  • Pluto: about 40 members (mostly engineers) already used Claude. The IT lead sent notice 2 weeks ahead, and everyone migrated within the window. The CIO holds Primary Owner, deliberately out of daily use.

Module 2 — Structure & Identity

Lesson 4: One organization or many

  • An organization is the boundary around members, groups, settings, and data. Nothing crosses it: projects, chats, artifacts, skills, and settings all stay inside.
  • Several orgs can sit under a parent organization that shares the IdP, domain verification, SSO, and provisioning. Billing and usage stay per org.
Choice When
One org (default) None of the three situations below applies. Use groups for internal separation. Separate caps or a stricter posture for one unit is group/role work, not a reason to split.
Split on contract lines Units need separate Anthropic contracts, not just separate cost centers
Split on identity lines Distinct IdPs that can’t be joined (e.g., Okta vs. Entra)
Split on data-isolation lines Regulation or contract requires walling off data. Get the compliance owner to confirm.
  • Change later: a merge or split is a full rebuild (new org, domain verification, re-provisioning). Adding a second org later is cheaper than pulling apart one you over-consolidated.
  • Provisioning:
    • JIT creates a member at first sign-in. Groups don’t sync, so you maintain them by hand.
    • SCIM pushes members and group memberships ahead of time, so Claude follows directory changes. A control is only as accurate as the membership list underneath it.
  • Pluto: one contract, one IdP, and no isolation need, so it runs one org. Payments & Trust is handled with groups.

Lesson 5: Your groups

  • A group is a named set of members (synced via SCIM or created by hand). Nearly every later control attaches to groups, and one group structure spans all surfaces.
  • If you want “just these three people” or “everyone except contractors,” that’s a sign you need another group.
  • RBAC: members → groups → roles. Change a role, and every member of that group changes at once.
    • Admin roles: Primary Owner, Owner, Admin.
      • An Admin manages members but not billing.
      • Editing caps and viewing billing are Owner+.
      • Data export and transferring Primary Owner are reserved for the Primary Owner.
    • User role.
    • Custom roles set four things:
      • Capabilities (e.g., Claude Code, Cowork)
      • Model access
      • Connector permissions (including write)
      • Admin permissions
    • These four only take effect for members on a Custom role. Built-in roles get everything that’s enabled org-wide.
  • Union rule: a member in several groups gets the union of all their groups’ roles. A narrower group cannot remove what a broader one grants. To bound people tightly, put them in a dedicated group and keep them out of the broad group.
Pattern When Trade-off
Mirror org chart Controls vary only by department A cross-department risk boundary has no group to attach to
Tier by risk A regulated function needs tighter controls than its department Everyday per-department controls have no group shaped for them
Hybrid Department groups plus a carved-out group for the boundary The usual landing spot. Keep carved-out members out of the broad group.
  • Change later: groups themselves are cheap to add, rename, or re-role. The IdP-group→role mapping is the risky part: changing it is a mass access change, and reverting it is a second mass change.
  • Pluto: hybrid, with one group per unit plus a cross-unit Engineering group. A dedicated payments-eng group keeps payments engineers from inheriting Engineering’s broad connector access through the union.

Module 3 — Access

Lesson 6: Surfaces each group gets

  • A surface is a place members use Claude: chat, Cowork, Claude Code, Claude for Microsoft 365, and so on.
  • Two layers, and both must allow it:
    • The org-wide toggle is the ceiling.
    • The role grant decides who has access under that ceiling.
  • Claude Code is granted the same way. Its managed settings (files, commands, network destinations, an optional pinned default model) are written by the platform lead. Which models are available is still governed on the Models page.
  • Models & effort:
    • Org default model: it holds through model releases until you change it, and changing it resets members’ own picks. It can be set by an Owner, the Primary Owner, or a custom role with the Identity & Access permission.
    • Per-role defaults: a custom role can carry its own default model, plus a default effort level.
    • Org-wide limits: turn models on or off, and set an effort cap per model. No custom role can exceed it.
    • Per-role limits: a model subset and lower effort caps. Haiku is always available.
    • Why adjust: spend (most people use whatever default they see) and task fit (coding vs. routine drafting).
Choice When
Broad first, specialized where needed No reason to hold back. Give general surfaces everywhere and specialized ones (Claude Code) only where daily work calls for them.
Pilot, then widen The objective calls for testing with one team first
Phased in behind a review A constraint means a group waits until a review clears
  • Change later: granting later is cheap. Revoking breaks workflows people built on the surface.
  • Pluto: chat and Cowork for everyone; Claude Code for Engineering and Platform. payments-eng waits for Claude Code until visibility reporting is in place.

Lesson 7: Connectors

  • Connectors (built on MCP) let Claude read from and act in your tools: drive, wiki, ticket tracker, and so on. An early connector is a high-leverage adoption move.
Gate Controls Set by
Organization Whether the connector exists in the org at all Owner / Primary Owner
Role Whether a group’s role includes it (role’s Connectors tab) Owner / Primary Owner
Member Whether the member connected their own account Member (or EMA)
  • Each connector tool can be set to “Always allow”, “Needs approval”, or “Blocked”:
    • Existing custom roles default to “Always allow” on every connector. Check each one.
    • New custom roles start at “Needs approval”.
    • Block a connector’s write and delete tools to keep it read-only.
  • Claude inherits the member’s own permissions in the source system.
  • Enterprise-managed authorization (EMA): provision connector access centrally through the IdP, so everyone in scope gets it at first login. It only works for connectors whose provider supports it.
  • Read vs. write:
    • Read (fetch/search) is lower risk.
    • Write (file tickets, edit pages) lets Claude change data as the member. The data-risk owner should sign off on write grants.
  • Raise Claude Code’s sandbox allowed domains in the same conversation as the connector list.
  • Announce each connector when it goes live. Route new-connector requests through the access owner.
Choice When
Read-only, scoped to groups whose work lives in that system Most orgs start here
Write, phased in with sign-off A workflow clearly needs write access and the risk owner agrees
  • Change later: freely reversible. Widening is free; narrowing breaks workflows, so announce it.
  • Pluto: drive and wiki read-only for all groups. Ticket tracker read-write for Engineering (risk owner signed off). payments-eng stays read-only, and connectors outside its remit are left off entirely.

Module 4 — Governance

Lesson 8: Governing customizations

  • What you govern:
    • Skills and plugins: a plugin bundles skills, connectors, and subagents. A plugin can’t grant a connector or capability the member’s groups lack.
    • Projects: shared context and files. Turning “Public projects” off makes every public project private, and they stay private if you turn it back on.
    • Organization instructions: always-on guidance included in members’ conversations.
  • Why govern: sharing spreads good workflows, but without governance you get sprawl (near-duplicate skills, untested workflows, over-shared sensitive projects).
  • Three questions:
    1. What can customizations do when they run? That depends on capabilities. Skills need both “Cloud code execution and file creation” and Skills turned on.
    2. Who can create and use them? Skills on/off is org-wide. A custom role’s Create skills and sharing capabilities decide who builds and who shares. Plugins can be assigned to a specific group.
    3. How do they move to everyone else? Four distribution controls:
      • Owner provisioning: pushes a skill to everyone, enabled by default. Owners, or roles with Libraries set to “Can manage”.
      • Skill sharing: to specific colleagues, who can use but not edit. On by default.
      • Share with groups: off by default.
      • Publishing: Off / Requires review / Open. With review, nobody can approve their own submission. The default varies by org, so check yours.
Posture When Settings
Open build, reviewed spread You want experimentation and have a CoE or champions to vet Skill sharing on; Publishing = Requires review
Centralized A staffed central team already owns internal tooling Skill sharing off; Publishing = Off; Owner provisioning only
Fully open Small or high-trust org All sharing on; Publishing = Open
  • Change later: loosening is free. When tightening, note that a stricter Publishing setting doesn’t remove already-published skills, so audit and remove those by hand.
  • Pluto: split posture. Most groups use open build with reviewed spread (a named reviewer per group). Payments & Trust is approve-first.
    • Org instructions: “You are assisting Pluto, a fintech with five business units… Customer-facing writing is plain and short, in Pluto’s house style.”

Module 5 — Spend

Lesson 9: Spend caps

Three levels, widest to narrowest:

  1. Org ceiling: the monthly total. Nothing exceeds it.
  2. Group caps: a per-member limit each member inherits. It is not a pooled group budget.
  3. Per-member overrides: for specific exceptions, above or below the group cap.

Seat default (under Spending defaults) applies before any group cap. For a member in two capped groups, the “Member limit from groups” setting picks whether the higher or lower cap wins, and the seat default counts in that comparison. Unlike the permissions union rule, you choose which wins here.

At the cap:

  • Usage pauses. Nothing is queued, and it resets monthly or when a request is approved.
  • The member sees an in-app request, which lands on the Usage page.
  • Approvers: Owners, the Primary Owner, or custom roles with Billing = “Can manage”.
  • Approvers often aren’t budget owners. Large orgs route requests through ticketing using the Spend Limits API (Admin API, public beta), which lists, approves, and denies requests and sets limits.

Sizing:

  • Use light / standard / power tiers by role type (from the consumption guide). Agentic surfaces consume more per session.
  • Considerations:
    • Size caps to typical usage.
    • Start tight and raise on evidence by re-basing to observed usage, not through repeated small increments.
    • Plan room for spiky work.
    • Prepaid credits: the ceiling is the remaining credit, and usage pauses org-wide at zero.
  • A growing override list is a signal that you need a new group.
  • Decide the escalation split up front: you approve routine requests, and changes to a group cap or the ceiling go to the budget owner.
  • Change later: free.
  • Pluto: after month one, a few heavy Platform engineers got overrides instead of a higher Platform cap. Payments & Trust reviews every request.

Lesson 10: Managing spend

  • Billing: a per-member platform fee plus pooled token consumption.
    • Sales-assisted contracts bill monthly in arrears.
    • Self-serve Enterprise prepays credits.
    • The pool is org-wide, and any level you leave uncapped is unlimited.
  • Levers that move spend without changing a cap:
    • Default model and effort level. This is the biggest lever, because most people never touch the picker.
    • Organization instructions (soft steering): short answers by default, only the files the task needs, and high effort only when the work needs it.
    • Skills and projects for reuse. A skill loads on demand, which costs fewer tokens than re-pasting prompts.
    • Agentic habits:
      • Scheduled Cowork tasks keep consuming whether or not anyone is watching.
      • “Run Cowork in the cloud” is off by default on Enterprise. Unified-experience members are an exception and run agentic work on Anthropic’s infrastructure anyway.
  • Review before you raise:
    • Question every increase.
    • Question every repeat: is usage growing, or was the cap set too low?
    • Review caps on a cadence in both directions.
Surface Answers Use for
Analytics dashboard Trends, spend by model, top consumers Regular review
Analytics chat Ad-hoc plain-language questions One-off questions
Analytics API Usage and cost data in your own tooling, by group Reconciliation and chargeback. The Primary Owner generates the key.
  • The Analytics API reads usage. The Spend Limits API sets caps. The spend CSV is per member, so join it to your group mapping for a group view.
  • Posture: start with a monthly review. Go weekly or biweekly early on, when a new surface launches, or when the budget is tight. A regulated group may need its own review.
  • Pluto: in month two, Platform hit its cap. The cause was the most capable model running routine PR summaries. Pluto lowered the default model on the Engineering role and left the cap where it was, and the next month Platform came in under the cap.

Module 6 — Visibility

Lesson 11: What you can measure

  • Set visibility up before members get access. Gaps in the record can’t be filled later.

The three pieces:

  • Compliance API: the content record.
    • Covers chat, Cowork, and Claude Code sessions: activity feed events, chat data, and file content, plus audit log events.
    • Route it to your SIEM, CASB, DLP, or eDiscovery tools, with a named reader. A record no one reviews isn’t a control.
    • The Primary Owner enables it.
    • Keys are scoped at creation: a Primary Owner key can cover the whole parent or a single child org, and an Owner key covers only that Owner’s org.
  • Audit logs: metadata only (who did what, when). They contain no prompts or completions.
  • Full data export: a separate, wholesale Primary Owner capability.
  • OpenTelemetry: operational “how it’s running” data, sent to your observability stack. It is optional.
    • Claude Code can opt in to prompt logging.
    • Cowork exports metadata only by default (the otlpContentCapture device policy turns on content), and some older versions send content anyway.
    • The metadata includes member emails and folder paths, so filter them in your collector if your policy requires it.
  • Retention:
    • The default is indefinite.
    • A custom window can be 30 days minimum, with no zero option. Chats inside a project follow the project’s window.
    • The activity feed is kept 6 years.
    • Remote/cloud Cowork transcripts are kept 6 years, unless a member deletes them sooner.
    • Local Cowork and Claude Code transcripts follow your custom window, or 6 years if you didn’t set one. With HIPAA readiness, they are kept 30 days.
    • Retention is org-wide, so the regulated group’s shorter window applies to everyone.
  • Inference hooks: a pre-answer allow/deny server that blocks content before it reaches Claude.
Choice When
Match existing data policy, Compliance API on The default. A policy and a review process already exist.
Regulated posture, Compliance API expected You handle regulated data. The risk owner sets the window.
Compliance API off, condition documented No review process exists or is planned. Write down the condition that turns it on.
  • Full data separation is the L4 org question, not a retention setting.
  • Change later: the Compliance API and OTel are toggles, but any stretch with the API off leaves gaps. Shortening retention deletes history permanently.
  • Pluto: the Compliance API went on before rollout and feeds the existing security review. OTel goes to Platform’s observability stack. Retention uses Payments & Trust’s shorter window, and the reviewer archives whatever must be kept longer before it’s deleted.

Lesson 12: Adoption signals

  • Breadth and depth signals are leading diagnostics, not proofs or quotas. Pair them with the outcomes of the work.
Signal Kind When low, look at
Active members by group Breadth Access and awareness/enablement
Members returning week over week Breadth Onboarding and first-session expectations
Chats per active member Depth Fit of surfaces and connectors to workflows
Skills/projects in use Depth Governance posture
Connector use Depth Connector scope (L7)
  • Include “Chat and Cowork unified” usage before you read a group’s depth as low.
  • Pace goal: concrete and readable. “Every granted group returning weekly within eight weeks” is a pace; “good adoption soon” is a wish.
  • Pluto: Ops was flat at about 10% active. That’s a breadth signal, and the cause was field staff who hadn’t had their enablement session. The fix was enablement, not settings.

Module 7 — Your rollout

Lesson 13: How the decisions connect

  • Compare your five answers with Pluto’s, and tie each one back to the objective. If you can’t explain the difference, revisit the decision.
  • Cascade: Structure → (Access, Governance, Spend attach to groups) → Visibility reads across everything.
    • Example: adding a group means it needs a surface grant, a connector scope, a cap, and a dashboard filter before it goes live.
  • A regulated function should be one posture, not five exceptions. Pluto’s Payments & Trust:
    • Its own group.
    • Claude Code held back, and connectors read-only.
    • Approve-first governance.
    • Every increase request reviewed.
    • It drives the short retention window, with the Compliance API read by a named reader.
  • Kickoff steps:
    1. Confirm the 4 hard-to-undo settings are either decided or have an owner and a decide-by date.
    2. Close open items. For each, write what’s blocking it, what unblocks it, and a date.
    3. Sequence the rollout: structure → access → governance → spend → visibility on → go-live by group. Each step gets an owner and a start date.

Lesson 14: When a new product arrives

  • Carries over: org boundary, groups and roles, governance posture, caps, and visibility pieces. Re-check them anyway; a genuinely new kind of product can add a question of its own.
  • Three questions to re-run:
    1. Who gets it? (the L6 decision again)
    2. What does it carry? Its own settings or connectors?
    3. Does it move risk? New data, new autonomy, or new audiences? If so, consult the risk owner.
  • Pluto + Claude Tag (Claude in Slack, beta):
    • It has its own identity and channel-scoped access.
    • By default it’s usable even without a Claude account, so Pluto turned on the role restriction.
    • Channel usage bills to the org, with its own limits and no upper bound until one is set, so the spend owner set those limits.
    • Pluto kept the default that blocks Claude in channels with a guest present (which also covers Slack Connect).
    • It stays off for Payments & Trust, and the risk owner signed off.

Quick-Review Flashcards

  1. Q: What are the five decisions, in order? → A: Structure & Identity, Access, Governance, Spend, Visibility. Each one scopes the next.
  2. Q: Which four settings are hard to undo? → A: Domain claiming, org topology, the group/IdP-role mapping, and data retention (deleted content is gone).
  3. Q: Which two decisions usually escalate beyond the Owner? → A: Spend (budget holder) and Visibility (data-risk owner).
  4. Q: What is “lockout insurance”? → A: At least 2 Owners assigned directly (or in the Owner-mapped IdP group before you save the mapping). Only the Primary Owner can recover access after a bad mapping.
  5. Q: Requirements for domain claiming? → A: Domain verified, Restrict organization creation on, SSO enforced, and provisioning live. Members get a 30-day window, and the claim is irreversible.
  6. Q: Name three valid reasons to run multiple orgs. → A: Separate contracts, IdPs that can’t be joined, or a required data-isolation boundary.
  7. Q: The union rule? → A: Permissions are the union of all a member’s groups. A narrower group can’t remove a grant, so isolate sensitive members in their own group.
  8. Q: The three connector gates? → A: Organization, role, member. EMA lets you provision the member gate centrally through the IdP.
  9. Q: The three governance postures? → A: Open build/reviewed spread, Centralized, and Fully open (Publishing set to Requires review, Off, or Open).
  10. Q: The three cap levels, and what a group cap means? → A: Org ceiling, group cap, per-member override. A group cap is a per-member limit, not a pooled budget.
  11. Q: What’s the biggest spend lever besides caps? → A: The default model and effort level, because most members never change the picker.
  12. Q: Compliance API vs. audit logs vs. OpenTelemetry? → A: Content plus audit events (Primary Owner enables it) / metadata only / operational telemetry (optional).

Practice Ideas

  • Write your company’s rollout objective (ambition + constraint) and test each of your five decisions against it.
  • Fill in the owner table for your company, and flag any decision that has no natural owner.
  • Run the six-prerequisite check, and draft the domain-claim member notice from the template.
  • Sketch groups using the hybrid pattern. Pick one regulated or sensitive function, put it in its own group, and check it against the union rule.
  • Build a surface × group grid (day one vs. phased) and a connector table (group, read vs. write), and list the write rows that need risk sign-off.
  • Choose a governance posture, name the reviewers, and draft 2–3 lines of organization instructions (including spend-steering lines).
  • Draft a cap table with light/standard/power tiers, an escalation split, and a “Member limit from groups” choice. Then simulate Pluto’s month-two request.
  • Write the visibility brief: Compliance API reader, retention window plus the policy it matches, and where telemetry lands.
  • Set a concrete pace goal, and decide what you’d do first if your most likely lagging group stays flat.
  • Run the three new-product questions on a surface you don’t use yet (e.g., Claude Tag).