SharePoint sync
How a SharePoint folder is copied into a knowledge base on a schedule, change by change, and who pays for it.
A SharePoint folder reaches agents in one way only: it is synced into a knowledge baseKnowledge baseKho tri thứcA collection of documents agents can search and cite. Files are uploaded or synced from SharePoint, and each knowledge base has its own sharing rules.Open in glossary, and agents search the copy. No agent reads SharePoint live. Each sync pass walks the changes SharePoint reports and files each one exactly as an upload is filed.
Key rules
- SharePoint is ingestion only — content reaches agents only through knowledge bases.
- One Entra app under
Sites.Selectedreads the folders it has been granted, nothing else. - Only changes are fetched: a delta link remembers where the last full pass ended.
- A pass is billed to whoever created the source, and pauses if that person has no live seat.
What a source holds
A SharePoint source names the tool it reads through (one Entra app granted Sites.Selected), a drive and a folder, and the delta link its last full pass ended on. Its schedule is a cron expression read in an IANA time zone stored beside it. Setting up the app and granting sites is on Administer → SharePoint; adding a folder is on SharePoint folders.
When a pass runs
A pass starts from any of:
- the sync button;
- resuming or taking over the source;
- the source being created;
- a sweep that runs every few minutes and queues every scheduled source whose cron slot, in its own time zone, has passed unrun.
Every one of these goes through the sync queue, which admits one job per source, so two passes over one folder never overlap. Which sources are due is answered by the sources table rather than the queue, so a source exists in one place. A pass resolves the paying department from whoever created the source, and pauses the source instead of running when that person has no live seat.
Per-change outcomes
For each change Graph reports:
| Change | Outcome |
|---|---|
| File deleted | Its document and passages go with it |
| Format the portal cannot read | Counted as skipped; its bytes are never fetched |
| Content hash matches the stored one | Title and link updated — this is what a rename upstream costs |
| Anything else | Downloaded, stored and given a job, exactly as an upload |
A sync checks readability twice: once from the name before downloading, and once from the bytes on arrival. What happens next is the knowledge pipeline.
Progress, pausing and resuming
The run row is written when the pass starts, again every ten changes with the counts so far, and once more when it ends, so a screen reading it during the pass sees the counts rise.
The cursor moves only after a full pass. A pass that breaks re-enumerates next time and matches on content hash rather than paying twice.
Between changes the pass re-reads the source. Anything that pauses it — a person pressing Pause, or a worker that ran out of budget — stops the pass at the next change, and the run is recorded as partial. Resuming a source whose payer has left is refused; taking it over is what gives it somebody to bill.
The source list shows each source’s document count and how many documents are still PENDING or FAILED, counted in one grouped read. A separate read returns the sources you pay for that have a pass running or documents still pending — that is what the activity tray polls.
Per-file settings at creation
Creating a source can give named files their own indexing settings, by the ids the preview listed them under. The preview names up to 500 files and counts every file. The first pass applies those settings as it files each one; a file a later pass files for the first time follows the source. A file the first pass failed to take counts as such a file, and so does every file when the first pass could not be queued.
First-sync estimate
The preview also estimates the first sync at each reading level, as a range in seconds.
- With history: once the organisation has five timed ingests at a level, the estimate reads the latest 200 and bounds the folder by their time per file and time per byte of the stored copy. Each document contributes one record, for its last run, timed from when the job starts.
- Without: page rates — 2 seconds a file, 3.87 seconds a page for OCR and 19.5 for a model, taking a scanned page as 700 KB and a text page as 100 KB.
Both divide by the ingest lanes the deployment runs. Neither counts queue time or a file’s own reading level.
Why it works this way
Why copy SharePoint instead of reading it live?
A copy can be read once — OCR, figures, rewrite — checked beside the original, and searched with the portal’s own visibility rules, at a known cost. Agents never need SharePoint credentials at question time.
Why bill the creator of the source?
A scheduled pass has no person in front of it. Tying it to the creator’s department gives every pass a budget, and a source with no live payer pauses rather than spending on nobody.