40 lines
1.8 KiB
Plaintext
40 lines
1.8 KiB
Plaintext
---
|
|
title: Known Limitations
|
|
slug: en/docs/known-limitations
|
|
description: Which limitations Tenantial names clearly on the public website so evaluations do not rest on silent assumptions or inflated marketing claims.
|
|
editUrl: false
|
|
lastUpdated: false
|
|
---
|
|
|
|
Known limitations are not a weakness in themselves. They are part of a credible product story because they help evaluators understand which statements are dependable today and which topics are intentionally not claimed.
|
|
|
|
## What this page covers
|
|
|
|
- which boundaries Tenantial names explicitly in public language
|
|
- why those limitations are useful for buyers, security, and procurement reviewers
|
|
- how clearer limitations lead to better next questions
|
|
|
|
## Typical boundaries worth naming openly
|
|
|
|
Tenantial does not claim generic multi-provider support, autonomous correction, blanket compliance outcomes, or automatic recovery on the public website. Keeping those limits visible makes the story more concrete and testable.
|
|
|
|
## Why this clarity helps
|
|
|
|
Clear limitations stop a pilot from inheriting silent expectations. Instead, they create room for the right follow-up questions around scope, roles, trust requirements, and credible handoffs.
|
|
|
|
## What buyers can infer from this
|
|
|
|
- Which statements are dependable today for Microsoft 365?
|
|
- Which topics need a later product or architecture decision?
|
|
- Where is public documentation enough and where is a real conversation still required?
|
|
|
|
## Boundaries of this page
|
|
|
|
This page is not a roadmap and not a total exclusion list. It only highlights the main points where conservative language matters more than a broader claim.
|
|
|
|
## Related links
|
|
|
|
- [Data processing & trust](/en/docs/data-processing-trust/)
|
|
- [Microsoft 365 Provider](/en/docs/microsoft-365-provider/)
|
|
- [FAQ](/en/docs/faq/)
|
|
- [Trust page](/en/trust) |