> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aiaxoniq.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Onboarding: enterprise

> Many teams, a security review, single sign-on and a staged rollout — the sequence that gets an organization onto aiAxonIQ without a re-do.

For an organization with several teams, a security review to pass, and identity
managed centrally. The technical work is the same as any other path; the
sequencing is what is different.

<Info>
  **Plan a quarter, not a week.** First data in an hour, one team productive in
  a week, an organization in a quarter. The long pole is almost never the
  installation.
</Info>

## Phase 1 — Decide the boundaries

Everything here is expensive to change once telemetry has accumulated.

<Steps>
  <Step title="How many organizations">
    An organization is the isolation boundary: separate telemetry, keys, users
    and plan, with **no cross-organization view**.

    Most enterprises want **one** — with `deployment.environment` and
    `service.namespace` separating environments and teams — because every
    additional organization means another place to look and another set of
    dashboards nobody shares.

    Choose more than one only where the requirement is genuinely *access
    control*: a regulated workload, a customer-isolated deployment, a
    subsidiary that must not see the rest. See
    [Organizations and multi-tenancy](/concepts/organizations).
  </Step>

  <Step title="A naming convention">
    `service.name`, `service.namespace`, `deployment.environment`. Agree it
    once, centrally, and write it down before the first team instruments
    anything — retro-fitting a convention across forty services is a quarter of
    someone's time.

    See [Resource attributes](/send-data/otel/resource-attributes).
  </Step>

  <Step title="Who holds which role">
    Viewer for most people. Editor for whoever maintains dashboards and alerts.
    Admin sparingly. **Auditor** for compliance reviewers — it grants audit-log
    access and no ability to change anything, which is exactly right and is
    frequently the role people did not know to ask for.

    See [Roles and permissions](/concepts/roles).
  </Step>

  <Step title="What must never be sent">
    Telemetry is append-only with no surgical delete, so this must be decided
    *before* ingest rather than cleaned up after. Redaction belongs at the
    Collector, in your network. See
    [Collector configuration](/send-data/otel/collector-config).
  </Step>
</Steps>

## Phase 2 — Security review

<AccordionGroup>
  <Accordion title="What leaves your network" icon="network-wired">
    Exactly one outbound destination over TLS, authenticated by a license key.
    The Collector is the single egress point, and it is the place to enforce
    what may and may not leave. See [Ingest endpoints](/send-data/endpoints).
  </Accordion>

  <Accordion title="Isolation between organizations" icon="lock">
    Tenancy is attached at the receiver from your license key and never read
    from the payload, so an exporter cannot claim to be someone else. Every
    query filters on it, and a request naming another organization is refused
    rather than silently corrected.
  </Accordion>

  <Accordion title="Credential handling" icon="key">
    License keys are shown once and stored only as a hash. They are revocable
    individually, so a compromised key is a rotation rather than an incident.
    Issue separate keys per environment and per agent — see
    [Create a license key](/get-started/license-keys).
  </Accordion>

  <Accordion title="Support access" icon="user-shield">
    aiAxonIQ support access is time-limited and recorded in **your** audit log,
    not only in an internal one. That is a control you can verify rather than a
    policy you have to accept. See [Audit log](/guides/audit).
  </Accordion>

  <Accordion title="If eBPF instrumentation is in scope" icon="microchip">
    It grants kernel capabilities on every node, and
    [Security model](/zero-code/security) is written to be forwarded to a
    reviewer unedited.

    **Two things a reviewer will find, so raise them yourself:** there has been
    **no external security review**, and TLS library coverage is unmeasured.
    Both are stated on that page. Presenting them before your reviewer finds
    them is the difference between a caveat and a credibility problem.
  </Accordion>
</AccordionGroup>

## Phase 3 — Identity

Configure SAML against your identity provider before onboarding teams.

<Warning>
  **SSO authenticates; it does not provision.** A user with no existing
  aiAxonIQ membership is refused with `403`, however perfectly their
  authentication worked.

  **Invite first, then have people sign in.** A rollout that enables SSO and
  announces it will generate a wave of confused `403`s on day one. See
  [Single sign-on](/get-started/sso).
</Warning>

Roles are managed in aiAxonIQ rather than mapped from identity-provider
attributes — so adding someone is always an explicit, audited act rather than a
side effect of a group change.

## Phase 4 — Pilot with one team

<Steps>
  <Step title="Choose a team with a real problem">
    A team that currently cannot answer a question they care about. A
    volunteer with nothing to diagnose produces a pilot that proves nothing.
  </Step>

  <Step title="Instrument one complete request path">
    End to end across every service it touches. A complete trace across five
    services demonstrates the value; partial coverage of twenty demonstrates
    the opposite.
  </Step>

  <Step title="Get to one real incident">
    The pilot succeeds when someone diagnoses something with it faster than
    they would have otherwise. Nothing else convinces an organization.
  </Step>

  <Step title="Write down what the team had to do">
    That becomes your internal runbook, and it is what makes team six take an
    afternoon instead of a week.
  </Step>
</Steps>

## Phase 5 — Roll out

<AccordionGroup>
  <Accordion title="Give teams a template, not a document" icon="copy">
    A Collector configuration and a set of environment variables they copy.
    Every team deriving their own from the documentation produces forty
    variations and forty naming conventions.
  </Accordion>

  <Accordion title="Watch usage from the first month" icon="gauge">
    Exceeding a volume allowance does not stop ingest, so nothing fails to warn
    you — the first signal is the invoice. **Settings → Usage**, monthly. See
    [Plan limits](/concepts/limits).
  </Accordion>

  <Accordion title="Centralise filtering and sampling at the gateway" icon="filter">
    One place, not forty. Health-check filtering and tail sampling belong on
    the shared gateway where they can be reasoned about. See
    [Sampling](/send-data/otel/sampling).
  </Accordion>

  <Accordion title="Cover what will never be instrumented" icon="wand-magic-sparkles">
    Every enterprise has services nobody owns and vendor images nobody can
    rebuild. eBPF instrumentation covers them without a code change — early
    access, and it needs the security conversation in phase 2. See
    [Zero-code instrumentation](/zero-code/overview).
  </Accordion>

  <Accordion title="Export the audit log on a schedule" icon="clipboard-list">
    The audit log is not exempt from retention. If compliance requires records
    for longer than the platform keeps them, a periodic export is the
    mechanism — there is no archive to request later. See
    [Audit log](/guides/audit).
  </Accordion>
</AccordionGroup>

## What will actually go wrong

<Warning>
  **Naming drift.** Six teams, six conventions, and a service list nobody can
  read. This is the failure that shows up in month three and costs the most to
  fix. Publish the convention, and check it at pilot rather than at scale.
</Warning>

<Warning>
  **Alert fatigue.** Every team creating twenty rules on day one produces a
  channel everyone mutes. Cap it: two or three rules per service to begin with,
  and require that each one be tested after saving — a rule with an
  unimplemented comparator is created without complaint and never fires. See
  [Alerting](/guides/alerts/overview).
</Warning>

<Warning>
  **Volume surprise.** Debug logging in one busy service, or one metric label
  carrying a request id, can multiply ingest overnight. Both are silent. Check
  usage in month one, not month four.
</Warning>

## Next

<CardGroup cols={3}>
  <Card title="Single sign-on" icon="fingerprint" href="/get-started/sso">
    SAML setup and the provisioning rule.
  </Card>

  <Card title="Kubernetes" icon="dharmachakra" href="/onboarding/kubernetes">
    The technical path most enterprises take.
  </Card>

  <Card title="Zero-code security model" icon="shield-halved" href="/zero-code/security">
    The document to forward to a reviewer.
  </Card>
</CardGroup>