Connecting your tools: where your data comes in
An assistant is only worth what it is allowed to read. So the first question is not what it can do, but what you can plug it into.
In short
Omniscient reads eight families of sources: uploaded files, structured files (spreadsheets and CSV), databases (PostgreSQL, MySQL, SQL Server, MongoDB), any REST API, Google Drive, SharePoint and OneDrive, HubSpot, and Notion. An IMAP inbox and an SMTP sending server complete the list on the automation side. Each connection is declared once, shared with whoever needs it, and reused everywhere it applies.
Which sources does the platform connect to?
Eight families of sources ship with the platform, and they overlap on purpose: the same data is often reachable by several routes, and the right route is the one that requires the fewest rights.
| Source | What it brings | Typical case |
|---|---|---|
| Uploaded files | Documents sent from the interface | A document set to bring in |
| Structured files | Spreadsheets and CSV read row by row | A monthly export, a reference list |
| Database | PostgreSQL, MySQL, SQL Server, MongoDB | A business tool with no API |
| REST API | Any service exposing a web interface | In-house software, a third-party service |
| Google Drive | Shared drives and folders | The company's office files |
| SharePoint and OneDrive | Libraries and team sites | The Microsoft document base |
| HubSpot | Contacts, companies, deals | The sales CRM |
| Notion | Pages and databases | Internal documentation |
Two mail protocols complete the list on the automation side: an IMAP inbox, which can start a scenario when a message arrives, and an SMTP sending server for the messages the platform produces.
Which file formats are actually read?
The distinction that matters is not the extension, it is what has to be done to get text out of it.
Office documents are read directly: PDF, Word, Excel, PowerPoint, as well as plain text and Markdown. Images are read through character recognition, which covers the scanned document and the screenshot pasted into a report. Structured files (CSV, TSV, spreadsheets) follow a separate path, because a table of thirty thousand rows is not a document: each row becomes an object in the knowledge graph, with its columns as properties.
Audio and video, on the other hand, are not transcribed. A meeting recording dropped into a connected source will produce nothing searchable. Saying so beats letting you find out: it is a frequent request, and the answer is no.
How is a connection declared, and by whom?
A connection almost always carries a secret: a password, a token, a key. That is what makes managing it different from an ordinary setting.
A connection is declared once, with a name and a sharing scope: kept to its author, opened to chosen people and roles, or opened to the whole organisation. The processes that need it reference it instead of copying its credentials. Three practical consequences follow.
First, a changed password is corrected in one place. Second, the secret is never readable: it is encrypted, and no read returns it, not even to the person who entered it. Third, the right to use it is checked twice, once when saving and again on every run, on behalf of the person who created the process. That second check is what makes a withdrawn share actually stop what depended on it, instead of leaving an access running that is no longer legitimate.
What can you see when a connection misbehaves?
An integration that fails quietly is worse than a missing one: nobody looks for what they believe they already have.
Every run leaves a trace you can consult, and the traces aggregate into a supervision console: the runs for the period, searchable logs, failures grouped by cause, documents in error with their reason, scheduled runs whose time has passed, and the associated consumption. A connection that has stopped responding therefore shows up as a dated fact, with its cause, rather than as an absence of results that nothing explains.
Should everything be connected on day one?
No, and that is rather the mistake to avoid.
What drives the time to get started is not technical, it is the number of sources retained and how clear the business vocabulary is. A first perimeter is most often limited to three or four sources, chosen because they carry the questions you want to be able to ask straight away. The rest are added once the vocabulary has settled, which avoids redoing extraction across the whole set.
Connected sources then feed both search across your documents and automations, without being declared twice.