What does Omni connect to?
The places your organisation already writes things down. Omni asks for what it needs by capability rather than by vendor: pages, work items, files, people, the software estate, control evidence. A provider satisfies a capability, which is why adding the second provider behind an existing one is cheap and why the list grows in families rather than one logo at a time.
How product connectors works in Omni
Live today: the Atlassian family
Confluence pages, Jira work items, goals and projects. Four connectors on a single grant, which is the pattern: one consent buys a family rather than a single integration.
Built, and set up with you
Files from Google Drive, SharePoint and OneDrive. Code changes from GitHub. People from Microsoft Entra and Workday. Messages, records and control evidence. Each is built and tested; connecting it to your tenant needs an app registration and your consent, which is engagement work rather than a wait.
Read-only wherever possible
A connector takes the narrowest access that does the job, scoped to the containers you nominate rather than the whole tenant, and every grant is logged and revocable.
What you get
- A model that stays current without manual re-uploads
- Access your security team can inspect, scope and revoke
- Second providers behind a capability rather than a longer logo wall
Common questions
Which connectors are live right now?
The Atlassian family: Confluence, Jira, goals and projects. Everything else is built and tested but is set up against your tenant as part of an engagement, because it needs an app registration and consent on your side. What is built today lists it connector by connector.
Why is the list organised by capability rather than by vendor?
Because Omni asks for what it needs by capability internally, and a website organised by logo would misdescribe the product. It also means a new provider behind an existing capability is an adapter rather than a project.