Integration · Knowledge + docs
On roadmap — not yet shippedClarityLift + Notion
Notion comment-thread signals on shared documents. Roadmap — not yet shipped. Document body content is out of scope.
Signals derived from Notion
Team friction (document-comment tone)
Communication health (response patterns on shared docs)
OAuth scopes ClarityLift requests
Every scope below has a documented purpose tied to a specific step in the data flow. ClarityLift never requests scopes it does not use.
read_content
Read pages the workspace explicitly shares with the integration
read_user_with_email
Resolve users for the consent gate
Data flow, end to end
- 1Workspace admin connects the ClarityLift Notion integration.
- 2Admin shares specific pages or databases with the integration (Notion’s default-deny model — no page is connected by default).
- 3ClarityLift polls the shared pages on a defined cadence for new comments (Notion does not yet expose comment-event webhooks reliably).
- 4Aggregate signals derived from comment threads.
What ClarityLift does NOT read on Notion
The privacy posture is led by what is excluded, not what is included.
- Direct messages between individuals — never read, ever.
- Group DMs — out of scope by design.
- Channel content from teams below the 10-member group floor.
- Personal account content of any kind.
- Page body content — never ingested.
- Database row content beyond comment metadata.
- Pages not explicitly shared with the integration.
Retention
No comment text persisted. Aggregate signals only.
Privacy considerations specific to Notion
- Notion’s default-deny sharing model is a feature, not a bug — connecting requires explicit page-level admin grants.
- Notion comment metadata can leak organizational structure (who replies to whom on what doc); ClarityLift surfaces only aggregate team-level patterns.
What the customer does at install time
- 1.Admin creates an internal Notion integration token.
- 2.Admin shares pages/databases with the integration.
- 3.Admin maps shared spaces to internal teams.