Choose a Data Source
Choose the system that owns the current version. A synchronized source is better than repeated uploads when content changes; Manual Upload is better when every version must be deliberately approved.
Decision Table
| Source | Use when | Enter in Data | Avoid when |
|---|---|---|---|
| Manual Upload | You have a small/test set, approved snapshot, or local export | One or more files | A live folder changes frequently |
| Google Drive | Google folders or Shared Drives own the live documents | Folder ID(s), recursive/shared-drive switches | The files belong to Microsoft 365 |
| OneDrive | One Microsoft user owns or receives the files | Drive-relative folder path(s) | A team site/library owns the content |
| SharePoint | Frequently changing team content lives in a site or document library | Exact library/folder path(s) | The files are personal OneDrive content |
| Azure Storage Account | An external system or pipeline publishes large blob volumes | Blob name/path/selector | The source is an SMB-style file share |
| Azure File Share | A large local/on-premises repository is exposed through Azure Files | Exact share name(s) | The source is a blob container or is not available through Azure Files |
| Jira | Current project issues should be searchable | One Project Key | You need one issue or arbitrary JQL |
| Confluence | One maintained space is the knowledge base | One Space Key | You need a single temporary page |
| Firecrawl | An approved website has no native connector | URL, mode, limit, optional path regexes | The site is authenticated or copying is not permitted |
Supported Files and Limits
The current RAG readers explicitly support these file formats for file-based Data sources:
| Content | Supported extensions |
|---|---|
| JSON | .json |
| Text and source code | .txt, .csv, .sql, .xml, .js, .mjs, .cjs |
.pdf | |
| Word | .docx |
| Excel | .xls, .xlsx |
| PowerPoint | .pptx |
| Markdown | .md |
The Other file class in the app is a filter category, not a guarantee that a parser exists. Do not assume that legacy .doc or .ppt files, images, or other binary formats can be indexed. Scanned PDFs and image-heavy Office documents may require advanced content extraction; always confirm their Indexed and Readable state and inspect representative extracted text.
Manual Upload and ZIP limits
These hard limits apply to Manual Upload, not universally to individual objects discovered by synchronized connectors:
- Each uploaded file, including a top-level ZIP archive, can contain at most
200,000,000bytes: 200 MB, or approximately 190.7 MiB. - One source-creation request can contain at most 1,000 directly selected files.
- ZIP is a transport container for Manual Upload, not a searchable RAG format by itself.
ZIP extraction is limited to 1,000 entries across the uploaded archives in one request, 200,000,000 uncompressed bytes per entry, and 500,000,000 uncompressed bytes in total. An entry's compression ratio cannot exceed 100:1, and its name cannot exceed 512 characters. Nested ZIP files, empty entries, unsafe paths, malformed or unreadable entries, and entries that exceed a limit are skipped. If no uploaded file or archive entry can be imported, source creation fails.
User RAG quotas
The Manual Upload per-file limit is separate from the cumulative ingestion allowance described in Data Upload Limits. The backend default is 500 MB per user, but an administrator can change the organization default or set a user-specific value. A 0 MB allowance blocks new documents with a positive size.
Advanced content extraction has a separate analyzed-page allowance. A page limit of 0, or a blank page-limit field in the app, means unlimited analyzed pages. These allowances apply across the user's Data sources. Synchronized connectors can also be constrained by their provider and the ingestion service, so the 200 MB Manual Upload limit must not be treated as a universal per-object connector limit. See Processing, Sync, and Troubleshooting for extraction and indexing checks.
Connection Versus Data Source
The connection stores authentication; the Data source stores scope. For example:
Connection: Support Google account (OAuth)
Data source: Folder ID 1AbC..., include subfolders
Collection: Customer Support — Approved Knowledge
Never paste API keys, OAuth tokens, Azure connection strings, or passwords into folder, blob, project, space, or URL fields.
Quick Recommendations
- Choose SharePoint for frequently changing team-owned documents that should synchronize from a governed site or library.
- Choose Manual Upload for small or test file sets and for snapshots whose replacement should be deliberate.
- Choose Azure Storage Account for large volumes delivered by external applications, exports, or automated pipelines.
- Choose Azure File Share for large repositories originating on local or on-premises servers after they are exposed or synchronized through Azure Files.
Automated local or on-premises feed
When an internal file server remains the source of truth, use a controlled synchronization service to publish only approved content to Azure File Share. Keep uploader write access separate from the Siesta AI reader, publish metadata after files are complete, and pilot update and deletion behavior. Follow Automated File Ingestion with Azure File Share.
Choose the Collection Boundary
Split collections when audience, owner, confidentiality, sync frequency, retention, or intended agents differ. Provider type alone is not the boundary: a collection may combine Jira and Confluence when they serve the same team and policy, while two Google folders may need separate collections if one is confidential.
Use durable business names such as Finance — Month-end Procedures, then identify implementation in the source name, such as Finance SharePoint — Approved library.
Source Ownership by Role
Users normally choose the material, verify documents, and test answers. Admins prepare shared connections, approve collection visibility, review least privilege, choose a service identity, and own credential rotation. See Use Sources and Govern Data.