---
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)