Connectors
Give your sandboxes access to WorkIQ services, Office 365, SharePoint, Jira, Salesforce, and 100+ more.
A connector links your sandbox group to an external service. Once attached, every sandbox in the group can opt in and call the service without its own OAuth flow, tokens, or secrets to rotate. To run sandbox actions in response to connector events, pair this with Triggers.
- Use MCP for AI agent to discover the tools at runtime inside the sandbox.
- Use an API Connector for static apps making calls over HTTP.
- The sandbox group has an identity attached (Attach an identity). The identity is what authorizes the group to use the connection.
- A connector in a connector namespace that you can attach. If you don't have one yet, use the 2-step portal quick start below, or follow the CLI quick start for the same flow from your terminal.
Create a connector in the portal (2 steps)
The portal at connectors.azure.com is the fastest way to get an MCP connector ARM ID for the snippets below. It handles OAuth consent for you and takes about a minute.
-
Create a connector namespace. Sign in with your work account and click + Create. To keep names aligned with the CLI snippets later on this page, use Name
my-namespace, Resource groupmy-rg(create it if needed), and the same region as your sandbox group (for examplewestus2). -
Add an MCP connector and pick SharePoint. Open the new namespace, go to MCP Connectors in the left nav, and click MCP Connector (Quick). The picker lists managed connectors grouped by family: Office 365, SharePoint, Teams, OneDrive, Salesforce, Jira, GitHub, ServiceNow, and 100+ more. Each tile shows whether it's a Managed connector (platform-managed, no configuration), Configurable connector (managed with configurable tools), or Hosted server (your own MCP server hosted as-is). Select SharePoint, name the MCP connector
office365Mcp, then complete the OAuth consent with the account that owns the site you want to expose. When it reaches Succeeded state, open it and copy the Resource ID from Overview. It ends in/mcpserverconfigs/office365Mcp. Pass this value to--connection-idin the snippets below.
# Save it as a shell var so the rest of this page works copy-paste.
# Replace <sub> with your subscription ID.
CONN_MCP_ID="/subscriptions/<sub>/resourceGroups/my-rg/providers/Microsoft.Web/connectorGateways/my-namespace/mcpserverconfigs/office365Mcp"
Prefer the CLI? Skip the portal and run the CLI quick start instead. It produces the same ARM ID.
Install the Connectors extension for Azure CLI
- Bash
- PowerShell
curl -fsSL https://aka.ms/connector-namespace-cli-install | sh
irm https://aka.ms/connector-namespace-cli-install-ps | iex
Smoke-test the install:
- Bash
- PowerShell
az extension show --name connector-namespace --query "{name:name, extensionType:extensionType}" -o table
az connector-namespace --help
az extension show --name connector-namespace --query "{name:name, extensionType:extensionType}" -o table
az connector-namespace --help
Attach a connector to your sandbox group
Adding a connector at the group level makes it available to every sandbox the group hosts. Each sandbox still opts in individually at create time.
- Agents (MCP)
- Apps (API)
# Fetch the MCP Connector ARM ID from your connector namespace
CONN_MCP_ID=$(az connector-namespace mcp-connector show -g my-rg --namespace my-namespace -n office365Mcp --query id -o tsv)
# Attach an authenticated connector to the sandbox group
aca sandboxgroup connector add --connection-id $CONN_MCP_ID --authorization system
# Verify
aca sandboxgroup connector list
# Point at the connection resource directly (no MCP wrapping)
CONN_API_ID=$(az connector-namespace connection show \
-g my-rg --namespace my-namespace -n office365Conn --query id -o tsv)
# Same command — the CLI keys off the /connections/ segment in the resource ID
# and auto-resolves connectionRuntimeUrl instead of mcpEndpointUrl.
aca sandboxgroup connector add --connection-id $CONN_API_ID --authorization system
aca sandboxgroup connector list
To attach more than one connector, run aca sandboxgroup connector add once per resource ID.
Attach a connector to a sandbox
Sandboxes do not automatically inherit the group's connectors, each sandbox opts in via --connection-id <id> [<id> ...] at create time (single flag, up to 10 resource IDs space-separated; immutable after create). Each resource ID must already be on the parent group.
- Agents (MCP)
- Apps (API)
aca sandbox create --disk copilot --label name=my-first-sandbox --connection-id $CONN_MCP_ID
# Verify the agent sees the MCP tools (ADC node agent auto-writes this file)
aca sandbox exec -l name=demo -c "cat /root/.copilot/mcp-config.json"
aca sandbox create --disk ubuntu --label name=my-first-sandbox --connection-id $CONN_API_ID
# Inside the sandbox, the API connector is reachable securely via the sandbox group's Managed Identity.
aca sandbox exec -l name=my-first-sandbox -c "echo ready"
Also available from the portal's Create-sandbox drawer via a connector picker.
Agent (MCP) via Copilot CLI (no code)
When you attach an MCP connector and boot the sandbox with --disk copilot, it auto-writes /root/.copilot/mcp-config.json and Copilot picks it up on its next run:
aca sandbox exec -l name=my-first-sandbox -c 'echo "Send a triage card to #infra-alerts when this build fails" | copilot --allow-all-tools -p @-'
Detach a connector
The remove command fails if any sandbox in the group still references the connection. Delete those sandboxes first.
aca sandboxgroup connector remove --connection-id $CONN_MCP_ID
Scenarios
Here are some flows you can build by combining connectors with triggers:
- Invoice extraction from SharePoint. A PDF lands in a SharePoint folder, a long-lived sandbox FastAPI receiver wakes up, and Copilot CLI uses
pdftotext/tesseractplus SharePoint MCP to extract structured JSON and write it back to SharePoint. See Sample 11. - PDF-only routing on SharePoint upload. Same flow as above, but a trigger
--conditionsfilter drops non-PDF uploads so the agent never runs on them. See Triggers → Filter events with conditions. - Email triage to a Teams channel card. Each incoming email to a watched Outlook mailbox spawns an ephemeral sandbox. The agent classifies the message and posts important ones to a Teams channel via MCP. See Sample 10.
- High-priority-only email escalation. Same architecture as email triage, but the connector's native
importance=Highparameter drops Normal and Low at the gateway, so no sandbox starts for them. - Coding agent with GitHub access. Attach the GitHub MCP and Copilot inside the sandbox can list PRs, open issues, read file trees, and push commits without any GitHub token visible to the sandbox. Requires
--disk copilotor--disk claude. - Agent sends or drafts email. The agent calls Office 365 MCP operations (
DraftEmail,SendEmailV2) from inside the sandbox to email a reviewer when a build passes. The same pattern works for Jira ticket creation, Salesforce lookups, and ServiceNow. - Sandbox as a direct webhook target. A long-lived sandbox FastAPI on
:8080is the webhook endpoint. The trigger POSTs directly to it via the ADC proxy, with no intermediate Container App in between. See Sample 11. - Hourly SharePoint compliance audit. A SharePoint connector trigger polling once an hour wakes a sandbox that scans a document library via SharePoint MCP and notifies on violations via Teams MCP.
- Daily email digest. An Outlook connector trigger polling once a day wakes a sandbox that reads the last 24 hours of email and drafts a digest.
Long-lived vs ephemeral sandboxes. Sample 10 spins up a fresh sandbox per event (run-a-command via an ACA receiver) for clean isolation at the cost of cold-start latency on each event. Sample 11 keeps one long-lived host sandbox (invoke-a-port directly to the sandbox port) for warm execution, with one sandbox shared across events. Pick the topology that matches your event volume and isolation requirements.