Data Upload Limits
Set two independent per-user allowances: Data storage and pages analyzed by advanced PDF extraction. Each applies across the user's Data sources. Neither grants collection access, sets a model context limit, or replaces the per-file Manual Upload limits.
Open Upload Limits
Open Admin → Limits → Data limits. Managing these limits requires DataSources.ManageLimits and its applicable view permissions. Active Admin mode is not required; selecting the Admin navigation tab does not enable it.
The Model limits tab is separate and requires Connections.ManageLimits. See Token Limits for model limits. Moving the editor does not change how storage or analyzed-page allowances are calculated.
Set the Default Policy
- Under Default policy, select Edit defaults.
- For each allowance, choose Unlimited or Limited.
- For a limited upload allowance, enter a value in MB or GB. For limited analyzed pages, enter a positive whole number.
- Review how many users follow each default, then select Save.
Each allowance inherits independently. Changing a default affects users who follow that default; it does not replace a custom value for the same allowance.
Set or Remove a User Override
Use Add override to find a user and open their limits, including users who currently follow the default policy. The Individual overrides table search filters existing overrides; an empty result there does not mean that the user is absent from the organization.
| Mode | What it does |
|---|---|
| Default | Follows the organization policy, including future changes |
| Custom | Keeps a fixed value for this user |
| Unlimited | Removes the cap for this allowance only |
Choose a mode separately for Upload limit and Analyzed pages limit, then select Save. For example, a user can have a custom storage allowance while continuing to inherit the analyzed-page allowance. A custom value equal to today's default remains custom.
To restore inheritance, use Reset to default, or select Default for the relevant allowance in the editor and save. Check the resulting policy after the change.
Storage accepts whole MB or a GB value equivalent to whole MB; 1 GB in this editor equals 1024 MB. A custom 0 blocks that allowance. Choose Unlimited explicitly when you need no cap; do not use an empty field or zero as a substitute. The organization-wide limited analyzed-page value must be at least 1; an individual custom value may be 0 to block paid analysis.
How Storage Is Enforced
Usage is calculated from the user's current documents across their sources, including stored originals even when not indexed. A file that would exceed the allowance is skipped with User storage limit exceeded. Existing processed content remains available. Removing documents releases their storage usage; it does not refund analyzed pages already consumed.
Review the actual usage together with the effective policy. Analytics provides a broader inventory view, but its periodically refreshed totals are not the quota check used before processing.
For a quota-blocked Manual Upload, the uploaded original is retained for retry after the quota is corrected. Confirm the next update's outcome rather than assuming that changing a limit completed ingestion.
Analyzed-Page Allowance
This allowance applies to Advanced content extraction of PDFs. Storage and analyzed pages are independent: increasing one does not increase the other.
Discovery estimates PDF pages locally without paid Document Intelligence analysis. After approval or automatic confirmation, the entire PDF must fit in the remaining page allowance before paid analysis starts. If it does not fit, it is skipped with User analyzed pages limit exceeded; Siesta AI does not analyze only the remaining number of pages.
The analyzed-page count is recorded when paid analysis returns, even if a later filter, unchanged-content decision, or indexing failure prevents a new indexed version. Repeated analysis can consume more pages. Deleting or skipping a document does not refund that usage.
For supported sources and deciding when to use this option, see Advanced PDF Content Extraction.
Scheduled Source Discovery and Incremental Reingestion
A connected source's schedule starts a new discovery run. It does not request full reprocessing of every file. Discovery enumerates the configured scope and identifies files that need estimation. With Auto-process discovered files off, those files wait for approval before indexing.
| File found during discovery | What happens next |
|---|---|
| New or changed | Estimate, review or auto-confirm, then process eligible content |
| Previously failed | Retry through the next discovery and approval flow |
| Unchanged after successful processing | Keep the existing indexed representation |
| From a rejected update | Discover again, even if unchanged |
| Previously excluded by a path regex that has been removed | Discover again on the next run, even if unchanged |
| Deleted by the user | Preserve that deletion; do not reingest |
Discovery can use provider API calls, pagination, downloads, and local parsing for estimates. It is not a promise of zero work or zero provider cost. Manual Upload has no scheduled connection to the original files on the user's computer.
Use Overview → Updates to compare runs and decisions, and Files to inspect individual outcomes. Discovery mode describes update states and approval behavior.
Technical Retrieval Path
File-count and token-count guidance for direct context and RAG is an operating heuristic, not an upload quota or an enforced product limit. Use the administrator decision table to select the initial approach, then validate it with representative questions.
For enterprise collections, use this retrieval path as the default technical design:
metadata filtering -> BM25 + vector search -> merge candidates -> reranker -> 10-30 chunks -> LLM
Metadata filtering narrows the authorized and relevant scope before retrieval. BM25 contributes exact lexical matches such as identifiers and product names, while vector search contributes semantic matches. Merge both candidate sets, rerank them against the user's question, and send the best 10–30 chunks to the model. The exact result count must be evaluated against answer quality, latency, and the deployed model's context window.
Chunk retrieval alone is often insufficient for comparison, synthesis, or reasoning across a corpus. In those cases, use retrieval to identify the relevant documents, then load the complete relevant documents when their combined size fits the model context. Do not load unrelated documents merely to fill the context window.
Troubleshooting
| Problem | Check |
|---|---|
| Upload limits is unavailable | Admin → Limits → Data limits, DataSources.ManageLimits, and applicable view permissions |
| Save is disabled | A value or mode must change; limited values must be valid in the selected units |
| User still cannot ingest | The user's effective mode, current usage, both allowances, and the file's actual skip reason |
| Source is waiting although capacity is available | Overview → Updates may require approval |
| Usage cannot be loaded | Retry the usage view; a loading error does not prove that usage is zero |