What Connectors is, precisely#
Connectors is the approved-source list: the accounts your workspace has registered, and the named resources inside each one that this workspace may read. It is a boundary, not a filter applied over a wider read.
Registering is not signing in
Registering a connector records an account and references a credential held in your own secret store. It does not sign in to anything, and it does not start a sync. Evidence arrives either from a local agent or through the authenticated ingestion API; the connector entry is what says that evidence was allowed to come from there.
No packaged connector mirrors a third-party system’s own permission model yet. That mapping is built with you per source during onboarding, and until it is, evidence pushed through the ingestion API carries the permissions the caller supplies.
The catalogue#
| Connector | Category | Auth | Default scopes |
|---|---|---|---|
| GitHub | Engineering | GitHub App | metadata:read, contents:read, issues:read, pull_requests:read |
| Jira | Work tracking | OAuth 2 | read:jira-work, read:jira-user |
| Slack | Collaboration | OAuth 2 | channels:history, channels:read, users:read |
| Microsoft Teams | Collaboration | OAuth 2 | ChannelMessage.Read.All, Team.ReadBasic.All |
| Notion | Documentation | OAuth 2 | read_content |
| Confluence | Documentation | OAuth 2 | read:confluence-content.all, read:confluence-space.summary |
| Google Drive | Documentation | OAuth 2 | drive.readonly |
Registering an account#
Press Connect a source
On Connectors. Choose the provider from the catalogue. This needs connector.manage.
Name the account
Something a colleague would recognise, such as GitHub, engineering. If you register two accounts at the same provider, this is how anyone tells them apart.
Give the external account identifier
The workspace or org id at the provider. It is what ties evidence back to a real account rather than to a display name somebody can change.
Reference the credential, do not paste it
The field takes a reference: projects/…/secrets/…, kms://…, secret://…. The credential stays in your secret store. If you find yourself pasting a token into this field, stop. That is not what it is for.
Trim the granted scopes
Pre-filled with the provider defaults, comma-separated. Remove anything you do not need. A scope you never use is a scope somebody can misuse.
Register
The account appears in the approved-source list with its sync mode, last scan, and any errors.
Naming the resources it may read#
A connector reads nothing until a resource inside it is named. Registration establishes the account; a resource scope is what opens a specific space, repository, folder or channel.
Open the connector and choose Allow a resource
Also gated on connector.manage.
Name it as a person would
A display name, such as Engineering handbook, and a resource type: folder, space, repository, channel.
Add each resource you intend to read
One at a time, and only the ones you mean. The scope list is the boundary.
The console cannot list existing scopes
The control plane exposes a write for a resource scope and no read, so the console can only show the scopes added in the current session. It says so rather than rendering “none”, which would be a measurement it has not taken. Keep your own record of what a connector is scoped to.
The boundary summary on that page#
Four values sit at the top of Connectors, and they are the workspace ceiling, not a per-connector setting.
- Default sync
- summary only. A redacted summary syncs; extraction stays on-device.
- Consent for sync
- Required. A source needs a standing consent decision before anything derived from it may sync.
- Raw upload
- Blocked by default. Raw source content does not leave a device unless an administrator explicitly enables it on a deployment profile.
- Local Agent
- Enabled. On-device knowledge is a source too, and the page links straight to inviting people.
Reading ingestion health#
Ingestion is the intake pipeline: what is waiting, what is running, what landed, what failed, and what gave up. Five counters:
| Counter | Means | Do you act? |
|---|---|---|
| Pending | Accepted, not started. | No. |
| Processing | Running now. | No, unless it never leaves this state. |
| Succeeded | Landed as evidence. | No. |
| Failed | A run errored. It will be retried. | Watch it. A rising count with a static dead-letter count usually means a transient upstream problem. |
| Dead letter | Retries exhausted. Nothing will ever pick this up again. | Yes. This is the one counter that should be zero. |
- A queue with jobs in it is a queue working. Pending does not raise an alert and should not worry you.
- The dead-letter queue does raise attention, because nothing will retry a dead-lettered job. Work it down to zero and keep it there.
- The connectors page carries the same reading as one line, n processing · n queued · n need attention, with Inspect pipeline next to it.
Where evidence lands#
Successful intake becomes an evidence object: immutable, with quote-level provenance, carrying its own access-control list. Evidence lists them with their sensitivity, and evidence is where every claim points when you ask “how do we know that?”
Where an evidence object's ACL comes from
- Captured by the local agent: always scoped to its device owner and to administrators, and additionally workspace-readable unless the extraction is marked confidential or higher.
- Pushed through the ingestion API: carries the permissions the caller supplies.
- Pushed with no permissions: given an explicit installation-wide read grant.
- Carrying no ACL at all: quarantined and returned to nobody. Retrieval fails closed, never open.
You are done when
Every account you intend to read from is registered with a credential reference rather than a pasted token, each has its resources named explicitly, and Ingestion shows a dead-letter count of zero.
Something here wrong, missing, or no longer true of the product? Write to hello@evodira.com. Documentation that has drifted from the console is a bug and we treat it as one.