AI's retrieval substrate
across system boundaries
What AI saw on any decision flows through the connector layer. Microsoft Graph, SharePoint, the MCP server, the schedule sidecar, inbound email, outbound webhooks, the OAuth integration manager. Per-org isolated; the retrieved context is captured in the per-project AI activity log alongside the action that followed.
The retrieval substrate behind AI decisions
Onplana's three-zone decision model (see the full post) commits in the act zone and proposes in the suggest zone. On every decision, AI is reasoning over context, and most of that context does not live in Onplana's own database. Connectors are how the context arrives.
The per-project AI activity log captures, for every AI decision, the prompt that triggered it, the retrieved context the model saw (including anything pulled in through Microsoft Graph, SharePoint, an MCP server, an inbound webhook, or the schedule sidecar), the action taken, the user, and the timestamp. That trail is the answer when an auditor asks "how was this status report generated" or "what data was the AI looking at when it flagged this risk."
Every connector follows the same posture: OAuth-gated where the upstream system requires it (Microsoft Graph, SharePoint, third-party file clouds), PAT-gated for programmatic clients (MCP, REST API, webhooks), per-org isolated at provision time so a token tied to org A cannot read or write to org B, audit-logged on every invocation.
Seven connectors shipping today
Direction, auth, plan tier, and what each one does. The integration roster expands by customer demand; vendors with significant overlap get prioritised.
MCP server
Onplana's tool catalog exposed over Model Context Protocol. Claude Desktop, Cursor, Goose, Continue, and any other MCP-compliant client can connect and use 200+ typed tools (read projects, create tasks, log timesheet entries, query risks, run governance reviews). Same gating + audit as the in-app chat.
Auth: OAuth 2.1 with Dynamic Client Registration (RFC 7591), or Personal Access Token
Microsoft Graph (M365)
Per-user OAuth to Microsoft Graph for mail (Mail.ReadWrite), calendar (Calendars.ReadWrite), Teams (ChannelMessage.Send + Chat.Read), files (Files.ReadWrite), people (User.Read). AI surfaces use it to summarise a thread, schedule a stakeholder meeting, post status updates to Teams channels, attach SharePoint docs to tasks.
Auth: Per-user OAuth, tokens refresh via lib/oauthTokens.ts, invalid_grant marks revokedAt
SharePoint sites + document libraries
Browse SharePoint sites the user has access to, attach SharePoint documents to tasks or projects without copying them into Onplana. Linked-mode (the file stays in SharePoint, Onplana tracks the link). The integration also surfaces document metadata in the project workspace.
Auth: Inherits the user OAuth scope from Microsoft Graph
Inbound email webhook (Project Mailbox)
Each project gets an inbound email address. Forward an email to it and AI parses it into the right shape: a new task, a comment on an existing task, or a status update. The original message attaches automatically. Stakeholder requests don't sit in inboxes waiting to be triaged manually.
Auth: Public webhook on /api/inbound-email, project-scoped via inbound address
Project schedule sidecar (.mpp / .xml / .xer ingest)
Upload a Microsoft Project file (.mpp, .mpx, MSPDI .xml, Primavera .xer) and the MPXJ-powered sidecar parses it into Onplana's task tree: tasks, dependencies (FS/SS/FF/SF + lag), ExtendedAttributes as custom fields, baseline + planned cost (from MSPDI). AI risk detection then runs over the imported schedule.
Auth: In-app upload (multer, 50 MB cap) or the free public version at /tools/schedule-health-check
Outbound webhooks
10 event types (project.created, task.completed, risk.detected, proposal.advanced, etc.). HMAC-SHA256 signed payloads, retry-with-backoff, delivery history per endpoint. Plug Onplana into Zapier, n8n, your own ETL pipeline, or your incident-response runbook.
Auth: Per-webhook secret, signed payload header (X-Onplana-Signature)
OAuth integration manager
The org admin UI for connecting third-party services (Google Workspace, Microsoft 365, Box, Dropbox, OneDrive, future targets). Token lifecycle managed through lib/oauthTokens.ts: refresh on stale, revoke on disconnect, mark dead on invalid_grant. Disconnect is soft (audit preserved), not hard-delete.
Auth: Org-tier permission (org.integration.manage, ADMIN+ default)
Auth + security posture
Three pieces that hold the same way across every connector.
Credentials in Key Vault
Onplana's third-party client secrets (Microsoft, Google, hCaptcha, Turnstile, Stripe, etc.) live in Azure Key Vault, rotated by ops out-of-band. Per-user OAuth tokens encrypted at rest in OauthConnection rows.
Per-org token isolation
Every PAT and OAuth token is scoped to one org at provision time. Connector calls cannot cross org boundaries because organizationId is bound to the token row, never read from a request header.
Audit on every invocation
Every connector call writes an AuditLog row. Outbound webhooks add a WebhookDelivery row with full request/response body + timing. Inbound email flows through the standard task/comment audit path.
What connectors don't do
The honest list for this layer.
Auto-execute destructive ops in connected systems
Connectors that write to external systems (Microsoft Graph mail send, Teams channel post, outbound webhook fire) follow the same propose-ratify pattern as native AI mutations. The action lands as a preview, the user confirms, only then commits.
Cross org boundaries
A PAT or OAuth token provisioned in org A cannot reach org B's data. Multi-org users connect each org separately. This is enforced server-side at the token row, not at the request header.
Bypass plan tier gating
Connector access maps to the org's plan tier: PRO+ for inbound email, BUSINESS+ for MCP / Graph / SharePoint / outbound webhooks. The gate is server-side; an MCP client can authenticate but tool calls that exceed the plan tier return 402 with the upgrade path.
Run autonomous multi-step work across systems
Connectors expose surfaces; the in-app chat and external agents drive them one tool call at a time. Multi-step agentic workflows that plan and execute across many connector calls live on the Agents layer.
Frequently asked
How are connector credentials stored?
Two layers. Onplana itself (Anthropic API keys, Azure OpenAI endpoints, third-party OAuth client secrets, SMTP credentials, hCaptcha, Turnstile, Stripe, etc.) lives in Azure Key Vault, rotated by ops out-of-band. Per-user OAuth tokens (each user's Microsoft Graph access + refresh tokens) live in OauthConnection rows in the org's database, encrypted at rest, refreshed automatically when stale. Disconnect is a soft revoke that preserves the audit trail.
Can a connector cross tenant boundaries?
No. Every connector call is gated by the same withOrganization middleware as the REST API: organizationId-pinned, X-Organization-Id-header-injected. A PAT or OAuth token is scoped to one org at provision time; nothing in the connector layer reads from a header passed at request time. Multi-org users connect each org separately.
What's in the audit log for a connector call?
Every connector invocation writes an AuditLog row (resource, resourceId, action, actor, details). Outbound webhooks additionally write to WebhookDelivery with the full request/response body and timing. Inbound email writes through the normal task / comment audit path. SOC 2 / SOX / HIPAA reviewers get the trail without extra wiring.
How does the MCP server differ from the REST API?
Same surface, different protocol. The MCP server speaks Streamable HTTP (the MCP transport standard) and advertises a typed tool catalog at /mcp/tools/list, so MCP-compliant agent clients discover Onplana's actions automatically. The REST API speaks HTTP+JSON and is documented at /api/openapi.json. Use MCP from a Claude Desktop or Cursor session; use REST from a backend script. Both call the same underlying handlers, with the same gating and audit.
Can I add a new connector that Onplana ships with?
Today the connector roster is the list above. The integration manager + OAuth refresh infrastructure is reusable, the bottleneck is per-provider OAuth setup + tool definitions. The Onplana team takes integration requests through hello@onplana.com; vendors with significant customer overlap (e.g. Atlassian, ServiceNow, Salesforce) get prioritised.
Why is the schedule sidecar listed under Connectors?
Because it reaches OUT of Onplana's own data model to ingest a foreign file format. The MPXJ Java sidecar (running as a separate Container Apps Job) parses .mpp / .xml / .xer, hands the parsed shape back through HTTP, and Onplana's import pipeline writes it into the project tree. It's a connector to the Microsoft Project file world, same way the SharePoint integration is a connector to the document-cloud world.
Continue through the AI cluster
Connectors are one of three layers. The other two cover the in-product AI surfaces and agentic multi-step work.
Native AI
The act zone: AI commits directly. Plan draft, NL parsing, status draft, portfolio Q&A, recommendations.
Read moreYou're here, Connectors
AI's retrieval substrate across system boundaries.
Agents
The suggest-zone propose-ratify model: risk flags, resource shifts, what-if, scope impact, baseline drift.
Read moreSee the connectors in your org
Sign up free, connect Microsoft Graph or upload a .mpp file in two minutes, watch AI surfaces start pulling context from across your tools.