ahmido
af5fa30341
Implements website feature branch `410-public-docs-ia`. Target branch: `website-dev`. Validation: - `corepack pnpm --filter @tenantatlas/website build` - Playwright smoke coverage for public routes and docs interactions - Static claim scans for `apps/website/src`, `apps/website/public`, and `apps/website/dist` Follow-up integration path after merge: `website-dev` -> `dev`. Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de> Reviewed-on: #412
41 lines
2.1 KiB
Plaintext
41 lines
2.1 KiB
Plaintext
---
|
|
title: Getting Started
|
|
slug: en/docs/getting-started
|
|
description: How evaluators and buyers can use the Tenantial docs hub to shape a pilot, align stakeholders, and focus Microsoft 365 governance conversations.
|
|
editUrl: false
|
|
lastUpdated: false
|
|
---
|
|
|
|
When you first evaluate Tenantial, a long feature tour is rarely the best place to begin. It is usually more useful to clarify which governance questions are currently messy in Microsoft 365 and which stakeholders will later need to discuss evidence, risks, and next steps.
|
|
|
|
## What this page covers
|
|
|
|
- which questions should be answered before a demo or pilot
|
|
- which teams are typically involved in evaluation, review, and approval
|
|
- which information the public website intentionally does not collect or promise
|
|
|
|
## Start with the right framing
|
|
|
|
Tenantial is designed for readable governance work: known state, visible change, evidence, findings, and the next decision. A strong starting point is therefore a short discussion of which policy families, reviews, or recovery scenarios currently create decision pressure.
|
|
|
|
## Useful preparation
|
|
|
|
- Note which Microsoft 365 areas repeatedly require manual review work today.
|
|
- Capture which roles need to read evidence, weigh risks, and approve follow-up.
|
|
- Separate confirmed facts from open trust or security questions so the demo does not become overloaded with assumptions.
|
|
- Do not send credentials, secrets, or tenant exports through the public website.
|
|
|
|
## What a good first pilot looks like
|
|
|
|
A credible pilot stays small, clear, and reviewable. It proves one concrete governance value, answers the most important trust questions early, and leaves later rollout or architecture decisions where they belong.
|
|
|
|
## Boundaries of this page
|
|
|
|
This page does not replace a permission matrix or a rollout plan. It only helps frame the first decision and structure the next conversation.
|
|
|
|
## Related links
|
|
|
|
- [Evaluation & pilot](/en/docs/evaluation-pilot/)
|
|
- [Microsoft 365 Provider](/en/docs/microsoft-365-provider/)
|
|
- [Permissions & data access](/en/docs/permissions-data-access/)
|
|
- [Trust, privacy & security](/en/trust) |