Skip to content

Microsoft Connectors Setup

How to register the Entra application that powers the Microsoft connectors - outlook-mail, outlook-calendar, onedrive, and sharepoint - for a university, and wire it into CampusCore. The four connectors share one app registration; each university registers its own app in its own Microsoft tenant - CampusCore never shares an app registration between clients.

What the connectors do

The Microsoft connectors give the assistant delegated access to Outlook mail, Outlook calendar, OneDrive files, and SharePoint document libraries on behalf of each connected user - one connector per product, so admins enable, test, and govern each product independently, and each user connection carries a token scoped to that product alone. Every call runs on that user's own OAuth token, so Exchange Online, OneDrive, and SharePoint enforce all data scoping - the assistant can never see mail, files, or sites the user cannot see. Write actions (drafting, sending, organizing mail, creating or changing events, creating or organizing files) are held for in-chat user confirmation and are additionally disabled per role until a workspace admin enables them.

1. Register the application in Entra

Sign in to the Microsoft Entra admin center as a tenant admin.

  1. Go to Identity -> Applications -> App registrations -> New registration.
  2. Name it something recognizable, e.g. CampusCore Assistant.
  3. Supported account types: choose Accounts in this organizational directory only (single tenant). Single-tenant is the recommended posture: only the university's own accounts can ever consent.
  4. Redirect URI: choose Web and enter all four callback URIs - one per connector:
  5. https://<your-campuscore-domain>/api/connectors/outlook-mail/callback
  6. https://<your-campuscore-domain>/api/connectors/outlook-calendar/callback
  7. https://<your-campuscore-domain>/api/connectors/onedrive/callback
  8. https://<your-campuscore-domain>/api/connectors/sharepoint/callback
  9. Register, then note the Application (client) ID and the Directory (tenant) ID from the overview page.

2. Create a client secret

Under Certificates & secrets -> Client secrets -> New client secret, create a secret and copy its Value immediately (it is shown once). Set a calendar reminder for the expiry date - an expired secret breaks new connections and token refreshes for every connected user.

3. Configure API permissions

Under API permissions -> Add a permission -> Microsoft Graph -> Delegated permissions, add:

  • User.Read
  • Mail.ReadWrite
  • Mail.Send
  • Calendars.ReadWrite
  • Calendars.Read.Shared
  • Files.ReadWrite
  • Sites.Read.All
  • offline_access

This is the union of what the four connectors request; each connector's own OAuth flow asks only for its product's subset, so a user's outlook-mail token cannot touch files and their onedrive token cannot read mail. Calendars.Read.Shared is what lets the scheduling actions (get_outlook_calendar_free_busy, find_outlook_calendar_meeting_times) consider colleagues' availability, subject to the tenant's calendar-sharing policy. Sites.Read.All (sharepoint only) grants read access to the SharePoint sites the connecting user can already see - SharePoint enforces that user's own permissions on every call, and the connector is read-only.

Then click Grant admin consent for so users are not individually prompted to consent beyond the first sign-in. For sharepoint this step is mandatory, not just convenient: Sites.Read.All is a tenant-wide delegated permission users cannot self-consent, so without admin consent the sharepoint connect flow fails for everyone.

4. Configure the connectors in CampusCore

In CampusCore, go to Settings -> Workspace Connectors and open Configure on the first Microsoft connector you set up. Enter the Client ID, Client Secret, and Tenant ID there and tick Offer this configuration for sibling connectors to copy. Each remaining Microsoft connector then shows a Copy from ... option in its configuration form - use it, and the app registration's credentials are copied over and kept linked, so rotating them on the origin can update every linked connector in one save. Redirect URI and Scopes are per-connector and stay editable on every member. Set Tenant ID on the origin before copying: a linked connector's copyable fields only change through the link, so a tenant added to the origin later reaches the copiers via "apply to all", and a copier can never hold a tenant its origin does not.

Field Value Scope
Client ID the Application (client) ID copyable across the family
Client Secret the secret value from step 2 copyable across the family
Tenant ID the Directory (tenant) ID copyable across the family
Redirect URI that connector's exact URI from step 1 per connector
Scopes leave the default unless the university narrows the surface per connector

Enable each connector the university wants, then enable its write actions per role under the same screen - all writes ship disabled by design, so nothing can send or change data until an admin scopes it in. Enabling one product and testing it before connecting the others is the intended rollout path.

Narrowing a connector's Scopes narrows what every user's token for that connector can do; for example removing Mail.Send from outlook-mail makes sending impossible platform-wide while keeping drafting. A user who connected before a scope widening must disconnect and reconnect to pick up the new grant; until they do, an action needing the new scope fails and marks their connection as needing reconnection. A connector that saved its own Scopes value keeps it across upgrades - after an upgrade that widens the default scopes, edit the saved value to match or the new surface stays unreachable. One exception: the upgrade that split the former Microsoft 365 suite into the mail, calendar, and OneDrive connectors dropped the suite's saved Scopes value (a suite-wide string is wrong for every product) - a university that had narrowed the suite must re-narrow the affected product connector.

5. Verify

Connect a test account from Settings -> Connected Services on each enabled connector, confirm the granted-scope chips cover that connector's list, and ask the assistant something like "summarize my new email since yesterday" (outlook-mail), "what is on my calendar Thursday" (outlook-calendar), or "what SharePoint sites do I have access to" (sharepoint). The chips show what the token response reported: offline_access is typically omitted from it (the refresh token itself is the evidence), and personal Microsoft accounts fold or omit further scopes, so a subset of the requested list is normal - what matters is that the scopes the university expects for that product are present.

Development fallback (personal Microsoft accounts)

For local development without a work/school tenant, an app registration can instead choose Accounts in any organizational directory and personal Microsoft accounts and set TENANT_ID to common. Personal accounts cannot use findMeetingTimes, getSchedule for other people, or Teams meeting links - those need Exchange Online work/school accounts - and http://localhost:<port>/... is the only http redirect URI Entra accepts. Personal accounts also have no SharePoint sites, so the sharepoint connector can only be exercised against a work/school tenant. Never use the personal-account configuration for a university deployment.