What Each Product Sets Up
When you create a tenant, each product it was given is asked to set itself up in that tenant's database. Most of what a product needs arrives on its own. A few things cannot: anything that needs a credential, or a choice only the tenant can make.
This page is the per-product answer to two questions — what arrived, and what is left. The Products & Provisioning card on the tenant's page tells you which products have finished; this tells you what "finished" means for each one, and what the tenant's own administrator sees when they first open it.
How to read this
Each product reports two things back to the console:
- Provisioned — Its tables exist in the tenant's database and its defaults are in place. Nothing more is needed from you.
- Setup steps — Things the tenant's administrator completes inside the product itself. A required step means the product is not usable until it is done; an optional one is a refinement.
A step completes on its own as soon as the thing it asks for exists. If a tenant was already configured — an older tenant, or one an engineer set up by hand — its steps show as complete the first time anyone looks, and nobody is asked to redo work that is already done.
Note: Steps are the tenant administrator's work, not yours. You do not need to complete them before handing the tenant over.
Beak AI Agent Runtime
Provisioned automatically — Its schema, the shared agent tables, the built-in prompts, credential types, connector and notification templates, graph datasource configuration, and the tenant's own encryption key.
| Setup step | Required | What it asks for |
|---|---|---|
| AI provider | Yes | A model to run agents against — either a Beak Gateway key or a provider of the tenant's own. Nothing runs until this exists. |
| Hub connection | Yes | The tenant's Hub key, so agents can resolve tools from the Hub catalogue. |
| Notifications | No | SMTP relay for agent email. |
| Chat channels | No | Teams or Slack delivery. |
Beak AI Studio
Provisioned automatically — Its schema, the shared agent tables, the built-in skill types and connector catalogue, and empty configuration documents for the tenant to fill in.
| Setup step | Required | What it asks for |
|---|---|---|
| Gateway connection | Yes | Where Studio sends model traffic, and the key it uses. Without it the model list is empty and nothing can be tested. |
| Knowledge storage | No | The storage account for uploaded knowledge bases. A platform default can be used instead, which is a deliberate choice rather than an accident. |
| Default credentials | No | Provider credentials shared across the tenant's agents. |
Beak AI Security and Governance
Provisioned automatically — Its schema, the full built-in validator catalogue, the baseline guardrails, and the default policies.
| Setup step | Required | What it asks for |
|---|---|---|
| Guardrail baseline | Yes | Confirms the built-in validators are installed. Completes on its own at provisioning. |
| Policy in force | Yes | At least one active policy, assigned to something. Provisioning installs policies; putting one in force is the tenant's decision, so this waits for a person. |
| Agent governance | No | Governance settings for the tenant's agents. |
Beak AI Gateway
Part of Beak AI Security and Governance. It is not entitled or sold separately: a tenant given that product gets the Gateway with it, and a tenant without it does not get one at all. That is why it has no row of its own in the product list even though it has its own schema and setup steps.
Provisioned automatically — Its schema, the model catalogue the picker lists, the per-provider credential forms, the alert channel types, and a default project and team for usage to be attributed to.
| Setup step | Required | What it asks for |
|---|---|---|
| Add a model | Yes | At least one active model. Until one exists every product routing through the Gateway sees an empty model list. A model needs a provider credential, which is why provisioning cannot add one for you. |
| Teams and budgets | No | Further teams, spend caps and rate limits. A default team is created for you. |
Beak AI Observability
Provisioned automatically — Its schema, with the trace, span, evaluation and alert tables partitioned by time so they stay fast as they grow.
No setup steps. There is nothing for an administrator to configure: traces arrive from the other products as the tenant uses them, and alert and evaluation rules are opt-in whenever the tenant wants them.
Beak AI Hub
Provisioned automatically — The tenant is registered with the Hub and its system roles are created, so its users can browse and install from the catalogue.
| Setup step | Required | What it asks for |
|---|---|---|
| Hub key | Yes | The tenant's own Hub key. It is created from the Runtime setup wizard rather than here, so this step reports it rather than asking twice. |
Beak FinOps
Provisioned automatically — Its schema, the four system roles and their permissions, and the Admin role that a user arriving from Beak IAM is given. Nothing that costs money or holds a secret: no cloud account is connected for you.
| Setup step | Required | What it asks for |
|---|---|---|
| Create your organisation | Yes | The organisation whose cloud spend this tenant tracks. Every cloud account, resource and cost record is attributed to it, so nothing else can be set up first. |
| Connect a cloud account | Yes | Azure credentials for FinOps to read cost and usage data with. Until one is connected there is nothing to report on. |
| Microsoft Fabric | No | A Fabric workspace, to enrich cost data with your own analytics. |
| Budget alerts | No | Who hears about budget breaches and anomalies. Easier to decide once spend is actually flowing. |
Both required steps complete on their own if the tenant already has an organisation and a connected account — an existing tenant is not sent back through a wizard for work it did long ago.
Beak Enterprise License Management
Provisioned automatically — Its schema, the two system roles (Tenant Admin, Tenant Viewer) and their permissions, and the tenant's own record. The roles matter more than they look: outside Tenant Admin, every permission an ELM user has is read from that table, so a tenant without them can see nothing and sign nobody in.
| Setup step | Required | What it asks for |
|---|---|---|
| Company details | Yes | The company this licence estate belongs to. Every connector, contract and cost record is scoped to one. |
| Connect a source | Yes | At least one connector, so ELM can discover what software is installed and who is actually using it. Without one there is nothing to measure a contract against. |
| Add a contract | Yes | What the tenant has bought. Entitlements come from contracts, so compliance and savings stay unanswerable until one exists. |
| Alert rules | No | Who is told when a renewal approaches or a licence position slips. The dashboards report the same facts, so this is optional. |
All three required steps complete on their own where the tenant already has them, so an existing tenant is not sent back through a wizard for work it did long ago.
Beak M365 License Optimizer
Provisioned automatically — Its schema, the three system roles (Super Admin, Tenant Admin, Tenant Viewer) and their permissions, and the tenant's own record. That record is not bookkeeping: every user and every company is attached to it, so without it the tenant cannot create either.
| Setup step | Required | What it asks for |
|---|---|---|
| Company details | Yes | The company whose Microsoft 365 estate this tenant manages. Every connection, subscription and recommendation is scoped to one. |
| Connect Microsoft 365 | Yes | The Entra app registration M365 License Optimizer reads the estate through. Without it there are no subscriptions, assignments or usage to optimise. |
| First sync | Yes | One completed sync, so licences and usage are actually loaded. A connection that has never synced successfully leaves every dashboard empty. |
| Scheduled reports | No | Who receives the savings and waste reports, and how often. The dashboards report the same facts, so this is optional. |
All three required steps complete on their own where the tenant already has them, so an existing tenant is not sent back through a wizard for work it did long ago. "First sync" is the one that most often sits waiting: it ticks off by itself once the first sync finishes, which is usually minutes after the connection is saved.
Beak Observability
Provisioned automatically — Its schema, the three built-in roles (admin, editor, viewer) with their permissions, and an organization for the tenant. Both matter more than they look: a first-time sign-in only creates a user when the role the platform names for Observability exists and there is an organization to attach them to, so a tenant missing either admits nobody at all.
Provisioning does not create a local administrator account. Users arrive through single sign-on, and a password account is something an operator chooses, not something setting up a tenant should create.
| Setup step | Required | What it asks for |
|---|---|---|
| Company details | Yes | The company whose estate this tenant watches. Every monitor, host and alert is attributed to one. |
| Add a monitor | Yes | Something to actually watch. Until one exists there is nothing to alert on and no data to chart. |
| Where alerts go | Yes | A channel for alerts to arrive on — email, Slack, a webhook. A monitor whose alerts reach nobody is not monitoring. |
| Escalation policy | No | Who is woken next when the first person does not answer. Alerts still arrive without one. |
All three required steps complete on their own where the tenant already has them, so an existing tenant is not sent back through a wizard for work it did long ago.
Beak ITSM
Provisioned automatically — Its schema, the six system roles, and each company's starting configuration: business hours, categories for all five ticket types, an SLA, workflow statuses and notification templates. A tenant arrives able to raise a ticket, not with empty tables.
| Setup step | Required | What it asks for |
|---|---|---|
| Company details | Yes | The company this service desk runs for. Every ticket, workspace and SLA belongs to one. |
| Create a workspace | Yes | Somewhere for raised tickets to land. Without one there is nowhere to route them. |
| Business hours | Yes | When the desk is open. SLA clocks are measured against this, so targets cannot be calculated until it is set. |
| Ticket categories | Yes | A category for each of the five ticket types. A type with none cannot be raised at all. |
| Service level agreement | Yes | At least one SLA, so response and resolution targets exist. |
| Notification templates | No | Who is told when a ticket changes. Defaults are installed; tailoring them is optional. |
All five required steps complete on their own where provisioning already created them, so an existing tenant is not sent back through a wizard. They are the same checks the per-company setup wizard uses, so the two never disagree about whether a tenant is ready.
Shared components
Not everything in the Products & Provisioning card is a product you chose. Some rows are shared components — services set up behind the scenes, which appear there so you can see it happened.
There are two kinds, and the difference is who gets one:
- Set up for every tenant, whatever products they have. Infrastructure the platform needs regardless: no tile, nobody is given access to it, and no role mentions it.
- Set up with a particular product. A product can be served by more than one service, and the extra one is provisioned with it — so only tenants entitled to that product get it. Beak AI Gateway works this way: it comes with Beak AI Security and Governance. Unlike the first kind it is not invisible — it has its own schema and its own setup steps, listed above; what it does not have is a separate entitlement.
You do not choose either. Which services are components, and which product a component belongs to, is decided by the platform team and can differ by environment — so the card is the list. A tenant not entitled to the product simply does not show that component at all.
If a component shows as skipped, this environment has not been pointed at that service yet; the tenant is otherwise fine, and it is set up once the address is configured. That is different from not appearing at all: skipped means owed but not yet reachable here.
If a tenant is given a product later, its components are set up on the same run that provisions the product — there is nothing extra to do.
Where a product is set up
Each product answers from one address per environment, and every tenant on the shared platform is set up through that same address. A branded domain does not change it — beak.ultrasist.com.mx is the same installation as the platform address, reached by a different name, so those tenants are set up exactly like everyone else.
Where a product runs as a separate installation for one customer — its own deployment rather than a place on the shared one — that tenant is set up through its own address instead. Everyone else continues to use the shared one.
This is not an administrator setting and there is no screen for it. The platform team records it when the separate installation is built; if you are looking at a tenant and wondering which address it was set up through, ask them rather than looking for a field.
When a product shows as skipped
A product or component is recorded as skipped, not failed, when the environment has not been prepared for it to be provisioned automatically. Nothing is wrong with the tenant. Its schema is created the next time that product is deployed, and the platform team can complete it sooner. A failed product is different — it tried and could not, and the Run provisioning button retries it.