The records-of-record question shouldn't depend on where the file happens to live.
Every regulated organisation eventually arrives at the same recognition: the documents that matter for audit, compliance, eDiscovery, and AI grounding live across 8 to 15 systems, and the question "which one is the source of truth?" has no good answer.
The Intelligent Repository is the platform that resolves the question. It federates content from where it already lives — M365, SharePoint, the legacy DMS, Box, the supplier portals, the line-of-business applications — and makes the records-of-record question answerable in one query. Every event on every document writes to the same audit chain. Every retrieval respects the same permission model.
This is the foundation everything else on TeamSync composes onto.
Talk to a solutions engineer · See the platform overview · See the consolidation pillar
What "intelligent" actually means.
Most repositories are storage with permissions. The Intelligent Repository is storage that understands what the documents are.
| Capability | What it does |
|---|---|
| Federated capture | Native connectors to M365, SharePoint, Box, Drive, the legacy DMSes, and the LOB systems where regulated content already lives |
| Classification at ingest | Documents typed by content, not by storage location — contract, claim, batch record, FOIA response, regulatory submission |
| Permissioned retrieval | Every read bounded by the asking user's effective permissions at retrieval time |
| Audit-anchored | Every event hashed and chained at write time; verifiable cryptographically |
| Retention-aware | Per-document-type retention rules applied automatically; legal hold respected uniformly |
| AI-grounding-ready | Structured for retrieval by DocuTalk, Semantic Search, and Document Summarisation |
A repository that doesn't do all 6 is a storage system with retrieval. The platform's audit defensibility, AI grounding, and consolidation arguments all rest on this layer.
What composes onto the platform.
The Intelligent Repository is a foundation, not an endpoint. Every other capability on TeamSync reads from it or writes to it.
| Capability | What it does with the platform |
|---|---|
| DocuTalk | Reads — for citation-grounded answers |
| Semantic Search | Reads — for federated search across the estate |
| Document Summarisation | Reads — for grounded summaries |
| Agentic AI Workflow | Reads and writes — agents act on the platform |
| Contract Lifecycle Management | Writes — contracts become first-class records |
| eSignatures | Writes — signed artifacts become records |
| eDiscovery | Reads — hold and collection at the source |
| Business Process Automation | Writes — workflow events become records |
The composition is structural. There are no integrations to maintain. The audit chain is uniform.
How federation works.
The federation surface is what most legacy ECMs got wrong. They tried to ingest the content into a single physical store, which forced organisations into multi-year migration projects with mixed success.
TeamSync's federation is reference-based. The content stays where it already lives; the platform maintains the records-of-record metadata, the classification, the permissions, the retention rules, and the audit chain. When the platform needs to retrieve content (for AI grounding, for an export, for a hold), it reaches into the federated source.
| Federation pattern | Where it fits |
|---|---|
| Native connector — M365 / SharePoint | M365-resident content stays in M365; platform maintains records-of-record metadata |
| Native connector — Box / Drive | Same pattern for the major collaboration platforms |
| Legacy ECM connector | OpenText, Hyland, Documentum content remains accessible during migration |
| LOB-system connector | Documents from CRM, ERP, EHR, PLM federated by document type |
| Custom connector | REST + webhook support for the systems without a native connector |
The migration discussion stops being "move everything to the new ECM" and starts being "decide which records-of-record story we want for each document type."
What changes for the records officer.
The records officer's job moves from custodian-of-the-DMS to designer-of-the-records-of-record story. That's a meaningful shift in the kind of work the function does.
| Activity | Before | With TeamSync |
|---|---|---|
| Records-of-record per document type | Per-system, often inconsistent | Per-document-type, consistent across systems |
| Retention enforcement | Manual; varies by system | Automated; uniform |
| Hold enforcement across systems | Per-system, frequently incomplete | Native; one-query coverage |
| Audit response | Reconciliation across systems | Generated artifact from one chain |
| New regulator overlay | Per-system reconfiguration | Configuration on the platform |
How customers compare TeamSync for the platform.
The platform-level comparison usually compares against:
- OpenText Content Server / Documentum — broad legacy footprint; the modern AI copilot and the cryptographic audit are weaker
- Hyland OnBase — flexible customisation; the platform-platform architecture and the cross-source federation are weaker
- Microsoft 365 + Purview — strong inside M365; cross-source records-of-record and cross-system audit are weaker
- Box — strong on collaboration; the regulated-records platform and the cross-source federation are weaker
For specific comparisons: - TeamSync vs OpenText - TeamSync vs Hyland OnBase - TeamSync vs SharePoint + M365 - TeamSync vs Box
Read further.
- The platform overview — how the platform fits with the rest
- Why TeamSync — consolidate document sprawl — the architectural pillar
- Why TeamSync — tamper-evident audit — the audit chain the platform writes to
- Capabilities — the 16 capabilities, one platform