Connectors: Integrating Productivity Tools

What You Need to Know

Connectors are the bridge between Claude and the rest of your tech stack. Without them, Claude is limited to files on your local machine and whatever you paste into the conversation. With them, Claude can pull data from Salesforce, post to Slack, read your Google Calendar, update Jira tickets, and interact with dozens of other services — all without you leaving the Cowork interface.

But Connectors aren't a blank cheque. Every connector enforces a security model, requires explicit authentication, and operates within permission boundaries you control. Understanding how that model works is what separates competent Cowork users from people who either lock themselves out of useful capabilities or grant more access than they intended.

The OAuth authentication flow

When you install a Connector, you're not giving Claude your password. The process works like a hotel key card system. You check in once through a secure OAuth flow — a browser window opens, you authenticate directly with the external service (Google, Slack, Salesforce), and the service issues a scoped access token. That token tells the service exactly what Claude is allowed to do: read-only access to one folder, read-write access to a specific Slack channel, or full access to a CRM pipeline.

Claude never sees your credentials. It holds the token, and the token can be revoked at any time from the Connector settings in Cowork.

Installation and authentication are separate steps

This trips up more people than you would expect. Installing a Connector from the Browse Plugins menu adds it to your Cowork environment, but it can't do anything until you complete the browser-based OAuth flow. Installation is like plugging in a new appliance. Authentication is like turning on the power. Skip the second step and every request to that Connector will fail — either silently or with an authentication error.

The exam tests this directly. If a scenario describes someone installing a Connector and immediately trying to query data, and the query fails, the answer is almost always "they didn't complete the authentication step."

Granular permission controls

"Granular" means you choose exactly what Claude can do. A Google Drive Connector might offer:

• Read-only access to your entire Drive
• Read-write access to a specific folder
• Full access including shared drives

These aren't all-or-nothing choices. You select the scope during the OAuth flow, and you can change it later in the Connector settings. The principle is the same as folder scoping in Domain 2: grant the minimum permissions needed for your task, not the maximum available.

If you only authorised access to "My Drive" during the OAuth flow, Claude can't see shared drives, other users' files, or organisation-wide folders. This catches people out regularly — they install the Google Drive Connector, assume it can see everything, and then wonder why Claude reports "no files found" when asked to search a shared team folder. Review and adjust permissions in the Connector settings if broader access is genuinely needed.

MCP Apps: interactive UI inside the conversation

Standard Connectors return data as text — Claude describes your Jira board, lists your calendar events, or summarises your Slack messages in paragraph form. MCP Apps go further. They render interactive UI components directly inside the Claude conversation.

Instead of Claude describing your Asana board in text, an MCP App shows the actual board — drag-and-drop task cards, editable fields, live status indicators. Think of it as picture-in-picture mode for your favourite productivity apps, embedded right in the chat window. You can update a task deadline, reassign a ticket, or approve a pull request without switching to another application.

MCP Apps aren't proprietary to Claude. They use the open MCP standard and are supported by multiple AI clients, including VS Code and other development tools. Any exam option claiming MCP Apps only work inside Claude is a distractor.

Enterprise provisioning

In team and enterprise environments, individual setup gives way to centralised control. IT administrators can pre-install and configure Connectors for all users automatically — provisioning the Salesforce connection, the Slack integration, and the Google Workspace suite before anyone logs in for the first time.

This serves two purposes: it reduces onboarding friction (new team members start with working Connectors from day one) and it enforces consistent security policies (the admin sets the permission boundaries, not each individual user). Enterprise provisioning is covered in more depth in Domain 6, but the exam expects you to know it exists here in Domain 3.

Connector lifecycle: tokens expire

OAuth tokens aren't permanent. External services can revoke them, sessions can time out, and security policies can force re-authentication. When a Connector stops working unexpectedly, the first diagnostic step is always: check whether the token is still valid and re-authenticate if needed.

Connector tokens are also tied to your authenticated Cowork session. Log out, switch devices, or clear your session, and Claude loses access to the stored tokens. You must be logged into the same Cowork account that authorised the Connector for it to function.

---

Common Mistakes

---

Hands-On Activity

---

Practice Question

---

Sources

• Use plugins in Cowork — Anthropic
• Get started with Cowork — Anthropic
• Claude Cowork Guide 2026: Skills, Plugins, Connectors — FindSkill.ai