Skip to main content
Thread’s core promise — an outcome closes only when your own system of record confirms it — depends on Thread being able to read your systems. And most of the work guides and agents do — posting to a channel, sending an agreement, creating a project — happens through your systems. Connectors are both halves.

​
Reading: verification and context

Verification sources. A guide closes an outcome on a fresh read from a connected source, never on the agent’s say-so. Today’s guide tool gallery: a HubSpot record check (bound to the customer’s record at enroll), a Slack channel check, a Jira project check, a DocuSign envelope check, and a Gong call check. Every read lands in the watch log as a receipt. See Outcomes and verification. Milestone checks. Motion milestone verification can consult the read-only tools of any connected connector as evidence — CRM records, warehouse metrics, project status. When no read tool can verify a milestone, Thread says so honestly rather than guessing. See Milestones and verification. Context for agents. Agents get scoped read tools per connector — the deal and its stakeholders from your CRM, call transcripts from Gong, usage metrics from Snowflake, health and timeline from Planhat — so drafts and decisions start from real customer state.

​
Acting: triggers and delivery

CRM triggers. Salesforce opportunity stage changes, HubSpot deal stage changes, and Notion database status changes fire webhooks into Thread — creating accounts and routing them through workflows the moment a deal moves. Delivery and work. Agents act through connectors: post to Slack or Microsoft Teams channels, send email as the connected Gmail account, create calendar events with Meet links, send DocuSign envelopes, create and transition Jira issues, stand up Kantata projects, and write run summaries and tasks back to Planhat. State-changing actions follow per-action autonomy — anything not opted out of approval lands in your Inbox first.

​
The connectors

Salesforce

Opportunity-stage triggers, deep CRM reads for agents

HubSpot

Deal-stage triggers, guide record verification, CRM reads

Slack

Channel delivery, guide channel verification, approvals by DM

Google Workspace

Gmail sending, calendar events, Drive reads

Microsoft

Outlook email, Teams channels and messages

Notion

Database triggers or knowledge base, page reads and writes

Gong

Call transcripts for context, guide call verification

Jira

Project verification, issue reads and writes

DocuSign

Envelope sending and signature verification

Kantata

Services project creation and resourcing

Planhat

CSP context reads, timeline and task write-back

Snowflake

Read-only warehouse access, account-scoped metrics

​
Scope is the guardrail

There’s no separate permissions layer to author — each connection’s own scope bounds what Thread can touch:
  • Slack — the app sees only channels it’s a member of, and agents can’t name arbitrary destinations: posting tools resolve the channel server-side from your account and org configuration.
  • HubSpot — a guide’s record check is bound to the one record picked at enroll.
  • Jira — a guide’s project check is bound to the project you pin.
  • DocuSign and Gong — guide checks derive their scope from the email on the customer’s record, matched exactly at read time.
  • Snowflake — access is read-only and limited to the databases and schemas you grant in the setup script.
  • CRM reads — agents never pick which account’s records they touch; the account in context resolves it.
Thread connects one CRM at a time — HubSpot, Salesforce, or Notion in CRM mode. Notion connected as a knowledge base doesn’t count against this, so it can sit alongside your CRM.

​
Connecting and managing

Connections are managed on the Connectors page and are org-wide (Google and Microsoft email/calendar are per-user — each person connects their own account).
1

Connect

Most connectors use OAuth — click Connect, sign in, approve. Planhat and Kantata take a pasted API token; Snowflake generates a least-privilege setup script you run yourself.
2

Tokens stay encrypted

Credentials are stored encrypted in a vault — never in plain text, never exposed in logs — and refreshed automatically where the provider supports it.
3

Test and monitor

Each connector page has a live connection test. A connection that errors or gets revoked shows its status on the Connectors page.
4

Disconnect anytime

Disconnecting removes the stored credentials and stops everything that rides the connection — reads, triggers, and delivery. Data already written to the external system stays put.
Start with the connector that carries your verification: your CRM if outcomes live there, Slack if delivery matters most. You don’t need them all — each connector page says exactly what it unlocks.

​
Where connectors show up

  • Guides — tool rows you attach from the gallery; the read is the close. See Building a guide.
  • Motions — agent plays draw on connector tools; milestone checks read them for evidence. See Motions overview.
  • Workflows — CRM triggers start runs; routing decisions read CRM context. See Workflows overview.
  • Inbox — approval requests for state-changing connector actions, and external approvals delivered by Slack DM. See Inbox overview.