Organization Model

Factory's organization model lets an enterprise expand Droid across many teams without turning every team into a separate commercial or identity tenant. One enterprise root owns the contract, identity connection, billing relationship, and top-level administration. Organizations under that root provide operating boundaries where teams can manage membership, local admins, settings, credentials, usage limits, and regional posture.

Use this page to design the operating model before creating organizations under the enterprise root. For the step-by-step setup guide, see Organizations. For the management surface, see Admin Console.

Model at a glance

The enterprise root is the top of the Factory hierarchy. It owns the enterprise relationship and can govern the organizations below it. Each organization is an operating boundary inside that relationship.

Core concepts

What rolls up to the root

The root keeps the enterprise relationship centralized:

• one enterprise contract and subscription;
• one billing account and invoice;
• one SSO connection;
• one optional Directory Sync connection;
• enterprise-level visibility and administration;
• root-managed controls where the enterprise chooses to enforce them.

Organizations under the enterprise root should not be configured as separate SSO tenants or separate billing accounts. They are hierarchy and governance boundaries inside the same enterprise deployment.

What can differ by organization

Organizations provide separation where teams need different operating rules.

Design patterns

Create a separate organization when a group needs a real boundary, not only a label. The strongest signals are different admins, different membership, different credentials, different data residency, different model policy, or different spend controls.

Regional model

Use regional organizations when residency, local administration, or deployment routing differs by geography.

Acme Corp
├── Global Platform
├── Europe
│   └── Regulated Infrastructure
└── North America

Declare the region when creating the organization. Mixing regions in a hierarchy is supported when the enterprise intentionally wants different residency boundaries for different teams.

Regulated workload model

Use a nested organization for high-sensitivity work that needs stricter model access, lower autonomy, tighter command policy, or BYOK / customer-hosted inference.

Acme Corp
└── Product Delivery
    ├── Standard Workloads
    └── Regulated Workloads

This lets the regulated group inherit enterprise identity and billing while keeping stricter local controls.

Project or client delivery model

Consulting, agency, and client delivery teams often need a separate boundary per project or client environment.

Acme Consulting
└── Professional Services
    ├── Project A
    │   ├── Client Environment
    │   └── Restricted Work
    └── Project B

Use this pattern when credentials, repositories, or client-specific service accounts should not be shared across projects.

Department-only model, discouraged by default

Avoid mirroring the HR department chart as the default hierarchy. A department branch is useful only when the department itself needs separate administration, membership, credentials, data residency, model policy, or spend controls.

Acme Corp
├── IT
│   ├── Engineering
│   └── Operations
└── Finance

Use this model when those departments share one enterprise contract and SSO connection but truly need different owners, members, service accounts, and policy defaults. If the only difference is reporting, keep the organization structure simpler and use usage exports or analytics instead.

Naming and hierarchy guidance

Keep the hierarchy understandable for Finance, IT, security, and team admins:

• prefer two or three levels unless deeper structure is required;
• use stable names that match how the enterprise already refers to teams;
• avoid creating organizations only for reporting if membership and policy are identical;
• keep sibling names unique and easy to search;
• choose paths that make usage exports and access reviews readable.

Planning worksheet