SaaS Workflows
The Ozone Orchestrator is the multi-tenant cloud console where a tenant administrator manages everything for their organisation. This page is a conceptual overview of what an administrator does there, from bringing an environment online to routing a correlated problem to the right team. The AIOps pipeline that sits behind this flow is described in Platform Architecture.
1. Provision an environment and invite users
A tenant is the isolation unit: its own data partitions, quotas, and identity scope (see Security, multi-tenant isolation).
- Create the tenant. This establishes the tenant identity and the isolation metadata threaded through every store.
- Invite users and set roles. Add the people who will operate the environment and assign each of them a role (see section 2).
- Connect billing. Billing is handled through Stripe (card subscriptions and invoices) or Razorpay, both verified server-side. The chosen plan maps to a licence tier that caps collectors, devices, and retention, and governs what telemetry may be forwarded (see section 3).
2. Roles and access
Access to the console and the API is governed by five RBAC roles: SuperAdmin, TenantAdmin, Engineer, ReadOnly, and Auditor. Every service checks the caller's role against the action it is about to perform. The full role-by-permission model is the canonical Security & Compliance page.
User sessions carry a signed session token, verified at the gateway before a request is proxied and again by the target service. Collectors authenticate with a separate, long-lived collector token. See Security & Compliance for the full token model.
3. Enrol collectors and set ingestion policy
To bring a site online, the administrator issues an enrolment token and an ingest token:
- The enrolment token is one-time and expires after 72 hours. Hand it to the on-prem installer; it enrols one collector and is consumed on first use.
- The ingest token is bound to the tenant and routes forwarded telemetry to the correct place. Rotate it from the tenant integration config if it is ever leaked.
Ingestion policy decides what crosses the boundary and how fast. It is enforced on both sides: tier gating on the collector, and a per-tenant rate limiter in the cloud. Tiers scale from Trial (1 collector, up to 50 devices, 7-day retention, no AI, critical P1/P2 problems only) through Professional (5 collectors, up to 250 devices, 30-day retention, streaming events) to Enterprise (unlimited collectors and devices, 90-day retention, consolidated batch forwarding, cross-collector HA dedup, and payload encryption). The canonical per-tier caps and feature matrix live in Licensing & Tiers.
Lower tiers keep the full dataset on-prem and escalate only what matters, the data-minimisation property from Security & Compliance. Each tenant also has a per-minute ingest ceiling that scales with its tier; over-limit traffic is shed rather than allowed to overwhelm the pipeline.
4. Configure alerting, escalation, and integrations
The cloud consumes correlated problems and runs a dedup, suppress, and escalate flow before anything pages a human. Repeats within a dedup window increment a count rather than opening a new incident, maintenance windows and silences suppress expected noise, and an unacknowledged problem escalates to the next contact level on a schedule. The result is that one real incident produces one ticket and one page, not a storm.
Notification and ticket delivery itself happens on-prem, from the Ozone Data Collector's Integrations, not from the cloud. The collector delivers correlated problems to Slack, Microsoft Teams, Webex, PagerDuty, ServiceNow, Jira, or a generic webhook, so paging and ticketing keep working even during a WAN outage. Setup for each connector is in Integrations, available on the Professional and Enterprise plans.
5. View fleet, problems, and AI insights
The console gives a tenant administrator a single view of their estate:
- Fleet and heartbeat: every enrolled collector, its tier, and its last heartbeat.
- Critical problem matrix: the live P1 and P2 problems across the fleet.
- AI insights: the output of anomaly detection, forecasting, and LLM-driven root-cause analysis, with KPIs that click through to SLO, capacity, and security views.
- Inventory and topology: the device inventory with recent changes, and a network map.
- Dashboards: pre-provisioned infrastructure, health, alert, and capacity dashboards, plus capacity forecasts that project when a resource will hit its limit (AI capacity forecasting is a Professional and Enterprise feature).
What crosses the boundary
The edge and the cloud exchange a small, fixed set of records, and the raw telemetry firehose never leaves the edge. Upward, the collector sends aggregated heartbeats, compression statistics, and AI-triaged problem statements. Downward, the cloud sends upgrade commands and cross-site patterns. This is data minimisation in concrete form: the fleet keeps every raw event and metric local, and ships only what the cloud needs across the encrypted uplink.
| Next | Link |
|---|---|
| How tenant isolation and tokens are enforced | Security & Compliance |
| Where this telemetry comes from on-prem | Data Collector Deployment |
| Ingestion throttling, rate limits, webhook, RBAC faults | SaaS Troubleshooting |