Lattice Connectors let you connect your work accounts to supported productivity tools.
Lattice uses data from connected tools for specific AI functionality, such as drafting updates and reviews, as well as making it generally available to users in the Lattice Agent.
Lattice connects to your productivity tools with read-only intent and your own individual permissions. You connect your own account, and Lattice can only see data you can already see in that tool. Lattice never writes, edits, or deletes anything in a connected tool, and never expands anyone's access beyond what a tool grants them. Where a provider does not offer a suitable read-only permission, Lattice may receive broader technical permissions but only uses them for read operations, as documented below.
Depending on your role and on how the tool itself is configured, Lattice may be able access work by other people on your team, such as pull requests in a shared repository or tickets in a shared Jira project. Lattice uses this data to help ICs and Managers understand, summarize, and cite the work that happened in a period, across the Lattice features you use. Lattice never shares data requested on behalf of an individual with their manager or with other members of your organization without the explicit action of the individual (e.g. submitting an Update that your manager can read).
Data from connected tools follows the same storage, retention, and disconnect behavior as other Lattice data, documented here.
GitHub
API Documentation: GitHub REST API · GitHub GraphQL API · Scopes for OAuth apps
Connected data
When connected, Lattice syncs pull request, review, commit, and issue metadata from repositories you can access. Lattice does not read source code or file contents.
Data Type | How Lattice Uses It |
Pull requests the person authored (title, description, status, merge date, size of change, repository) | Shows the work you shipped. Merged pull requests are the strongest evidence of completed work |
Code reviews the person submitted (approved, changes requested, commented, and when) | Credits collaboration on teammates' work that doesn't appear in their own pull requests |
Commits the person authored (message and date) | Fills gaps where work landed by direct commit or where pull request descriptions are thin |
Issues and issue comments the person authored (title, status, close date, comment text) | Captures non-code work and decisions discussed in issues |
Your GitHub profile and organization memberships (username, orgs, teams) | Matches GitHub accounts to Lattice profiles and establishes which organizations' repositories are in scope |
Links to pull requests and issues | Provides a stable citation so anyone reading a summary can open the original work |
Permissions
Lattice requests scoped access via GitHub OAuth.
Scope | Purpose |
| Reads pull requests, reviews, commits, issues, and comments in public and private repositories you can access. GitHub does not offer a read-only scope for private repositories, so this scope technically includes write access; Lattice only ever reads |
| Reads your organization and team memberships so Lattice knows which organizations' repositories to search |
| Reads your GitHub profile (username, display name) to match your account to Lattice |
Jira
API Documentation: Jira Cloud platform REST API · OAuth 2.0 (3LO) scopes
Connected data
When connected, Lattice syncs issue metadata from projects you can access, for issues the person worked on.
Data Type | How Lattice Uses It |
Issues the person worked on (key, summary, status, resolution date, priority, issue type, parent epic) | Shows the tickets they completed and what is still in flight. Resolved issues are the strongest evidence of completed work |
Issue history (which fields changed, by whom, and when) | Shows how work moved through its workflow and who moved it |
Comments the person authored | Provides narrative in their own words |
Work logs (who logged time, how much, and when) | Reflects effort on teams that log time |
Jira profiles (account ID, name) for you and the people whose issues are read | Matches Jira accounts to Lattice profiles so work is attributed to the right person |
Links to issues | Provides a stable citation so anyone reading a summary can open the original ticket |
Permissions
Lattice requests read-only, scoped access via Atlassian OAuth 2.0.
Scope | Purpose |
| Reads projects, issues, and issue search results you can access, plus related comments, work logs, and change history |
| Reads basic user information (account ID, name, email) so issues can be matched to the right person |
| Lets Lattice refresh the connection in the background so you don't have to reconnect |
Linear
API Documentation: Linear GraphQL API · OAuth 2.0 authentication and scopes
Connected data
When connected, Lattice syncs issue metadata from teams and projects you can access, for issues the person worked on.
Data Type | How Lattice Uses It |
Issues the person worked on (identifier, title, description, status, completion date, estimate, labels, parent issue) | Shows the work they completed and what is in progress. Completed issues are the strongest evidence of completed work |
Project, cycle, and team each issue belongs to | Groups work into themes and time periods |
Comments the person authored | Provides narrative in their own words |
Linear profiles (user ID, name) for you and the people whose issues are read | Matches Linear accounts to Lattice profiles so work is attributed to the right person |
Links to issues | Provides a stable citation so anyone reading a summary can open the original issue |
Permissions
Lattice requests read-only access via Linear OAuth 2.0. Linear uses a single read scope rather than per-object scopes.
Scope | Purpose |
| Read access to issues, comments, projects, cycles, labels, teams, and users that you can already see in Linear. This is Linear's default scope and is always present; Lattice requests no write or admin scopes |
Notion
MCP Documentation: Notion MCP server · MCP supported tools and limits
Connected data
When connected, Lattice can search and read pages you have access to through Notion's hosted MCP server. Lattice looks up Notion pages as needed to find or corroborate work rather than syncing them in bulk.
Data Type | How Lattice Uses It |
Pages and databases you can access (title, link, parent page or database) | Finds documents related to the person's work and cites them |
Who created and last edited a page, and when | Attributes documents to the person and bounds them to a time period. Notion's API only exposes the most recent editor, not full edit history |
Database property values (status, person, date) | Reads structured status and ownership where teams track work in Notion databases |
Comments on a specific page | Shows discussion contributions on pages Lattice already knows about |
Meeting notes you created or attended (requires Notion Business plan or higher with Notion AI) | Surfaces meetings and decisions you were part of |
Your recent, favorited, and shared pages | Helps Lattice find your own active documents. These lists are always about the connected account, never about anyone else |
Permissions
Lattice connects through Notion's hosted MCP server using OAuth with dynamic client registration. Notion does not expose named OAuth scopes for MCP; access is governed by your own Notion permissions and the integration's capabilities:
Permission | Purpose |
Read content | Reads pages, databases, and property values you can already see in Notion. Lattice never sees pages you don't have access to |
Read comments | Reads comments on pages Lattice is already looking at |
Read user information (without email addresses) | Resolves creator and last-editor IDs to names so documents can be attributed to the right person |
Asana
API Documentation: Asana API reference · OAuth scopes
Connected data
When connected, Lattice syncs task metadata from projects you can access, for tasks the person worked on.
Data Type | How Lattice Uses It |
Tasks the person worked on (name, description, completion status and date, due date, milestone or approval type, parent task) | Shows the work they completed and whether it landed on time. Completed tasks are the strongest evidence of completed work |
Project and section each task belongs to | Groups work into themes and stages |
Custom field values on those tasks (for example status, priority, workstream) | Reads the structured fields the team uses to track work |
Task activity and comments (who said or changed what, and when) | Provides narrative in the person's own words and shows status changes |
Asana profiles and workspace for you and the people whose tasks are read | Matches Asana accounts to Lattice profiles so work is attributed to the right person |
Links to tasks | Provides a stable citation so anyone reading a summary can open the original task |
Permissions
Lattice requests read-only, scoped access via Asana OAuth.
Scope | Purpose |
| Reads tasks you can access, including name, description, assignee, completion, due date, memberships, and subtasks |
| Reads project names and sections so tasks can be grouped by project |
| Reads user profiles (name, email) so tasks can be matched to the right Lattice account |
| Reads task comments and activity history |
| Reads custom field definitions so field values on tasks can be interpreted |
| Authorizes read-only access to tags; Lattice does not currently use tag data |
| Authorizes read-only access to attachment metadata; Lattice does not currently sync attachments |
Monday
API Documentation: monday.com API reference · OAuth and scopes
Connected data
When connected, Lattice syncs items from the boards you can access that the person worked on.
Data Type | How Lattice Uses It |
Boards, groups, and columns you can access (names and column types) | Understands how each board is structured so items can be read and attributed correctly |
Items the person worked on (name, status and when it last changed, dates, timelines, numbers, subitems) | Shows the work they completed and what is in progress. Items marked done are the strongest evidence of completed work |
Updates the person wrote on items | Provides narrative in their own words |
Board activity logs (who changed which column, from what to what, and when) | Attributes status changes to the person who made them |
monday.com profiles (user ID, name) for you and the people whose items are read | Matches monday.com accounts to Lattice profiles so work is attributed to the right person |
Links to items | Provides a stable citation so anyone reading a summary can open the original item |
Permissions
Lattice requests read-only, scoped access via monday.com OAuth.
Scope | Purpose |
| Reads boards, groups, columns, items, subitems, and activity logs you can access |
| Reads profile information for users on the account so People columns can be resolved to names |
| Reads your own profile to identify the connected account |
| Reads updates and replies you can see on items |
| Reads workspace names so boards can be organized by workspace |
| Reads general account information (for example account name and URL) to build links to items |
Slack
API Documentation: Slack Web API methods · Scopes reference
Connected data
When connected, Lattice syncs posts in public channels only. Lattice never reads direct messages, group messages, or private channels, even ones you are a member of.
Data Type | How Lattice Uses It |
Messages the person posted in public channels (text, date, channel) | Identifies and corroborates work they announced. Slack is supporting context, never the primary evidence of completed work |
Thread reply counts and reactions on those posts | Distinguishes sustained discussion from one-off posts |
Files and canvases the person shared or authored (title and type only) | Shows artifacts they produced; Lattice does not download file contents |
Public channel names | Groups posts by channel |
Slack profiles (user ID, email) for you and the people whose posts are read | Matches Slack accounts to Lattice profiles so posts are attributed to the right person |
Links to messages | Provides a stable citation so anyone reading a summary can open the original post |
Permissions
Lattice requests read-only, scoped user-token access via Slack OAuth.
Scope | Purpose |
| Searches messages in public channels only |
| Searches for files and canvases shared in public channels (metadata only) |
| Legacy search scope used as a fallback for the |
| Reads basic information (names) about public channels so posts can be grouped by channel |
| Reads user profiles so posts can be attributed to the right person |
| Reads email addresses so Slack accounts can be matched to Lattice accounts |
Lattice deliberately does not request search:read.private, search:read.im, search:read.mpim, or any channel, group, or DM history scope. Without these scopes, Lattice cannot see your DMs or private channels, even when the people in them are the ones whose work it is reading.
Zoom
MCP & API Documentation: Zoom MCP server, Zoom Meetings API, and granular OAuth scopes
Connected data
When connected, Lattice syncs meeting metadata, AI Companion summaries, and transcripts for meetings you hosted or attended. Lattice never accesses or stores raw audio or video. Summaries exist only when AI Companion is enabled and the host is on a paid Zoom plan.
Data Type | How Lattice Uses It |
Meetings you hosted or attended (topic, start time, duration, host) | Shows which meetings happened in a period and bounds them to a time window |
AI Companion meeting summaries (overview, details, next steps) | Provides the written outcome of a meeting. Fetched on demand rather than stored in bulk |
Meeting participants (email, join and leave time) | Shows who was in the room so meetings can be attributed correctly |
Recording transcripts (speaker, text, timestamp) | Provides quotable evidence attributed to the speaker (requires cloud recording with transcription on) |
Cloud recording list and share links | Provides a stable citation so you can open the original meeting |
Your Zoom profile (user ID, email) | Matches your Zoom account to your Lattice account |
Permissions
Lattice connects once through Zoom OAuth and uses that single grant for both Zoom's hosted Meetings MCP server and a small number of REST calls. Lattice requests read-only, user-level granular scopes and no :admin or :master scopes:
Scope | Purpose |
| Searches meetings you hosted or attended through the Zoom MCP server |
| Reads meeting assets (AI Companion summary, transcript, share link) through the Zoom MCP server |
| Lists your cloud recordings |
| Reads recording resources such as the transcript file and share URL through the Zoom MCP server |
| Reads your own Zoom profile (ID, email) to identify you |
| Reads participant emails and join/leave times for past meetings |
| Reads a meeting's transcript with speaker names |
| Reads the AI Companion summary for a meeting through the REST API (fallback when the MCP summary shape is insufficient) |
| Reads past meeting details to resolve a meeting ID from its UUID |