All concepts
16 — Concept

Connectors

An organisation’s admin connects its Microsoft 365 once, and its directory and calendars sync in on a schedule — a connection for the organisation, not a login for one person.

Logging in is not connecting

The kit already signs people in with Google, Microsoft or an OIDC issuer. That asks one person who they are and keeps nothing else. A connection is a different grant with a different subject: an organisation's administrator lets your app read the organisation's directory and calendars, and your app keeps doing so on a schedule, whether or not anybody is signed in.

QuestionSign-inA connection
Who grants itthe person signing inthe organisation's admin, once
What it reachesthat person's own profilethe directory, and the calendars of your app's members
The tokennone kept in usean app-only token per organisation, cached encrypted
The app behind itthe kit's sign-in clienta separate Entra app, with its own permissions and review

Two plugins: one owns the rows, one talks to the vendor

Connections are not part of the kit. They are two optional plugins: connectors owns every table, route, cursor and schedule, and a provider plugin does the vendor's side of the conversation. Today there is one provider, m365, and it requires connectors — so connectors goes in first.

zsh — your app
pnpm plugin add https://github.com/rocketflare-dev/rocketflare-plugins.git@3.4.2 --subdir plugins/connectors --applypnpm db:generate --name plugin-connectors-3.2.0 && pnpm db:migratepnpm plugin add https://github.com/rocketflare-dev/rocketflare-plugins.git@3.4.2 --subdir plugins/m365 --applyrocketflare connectors statusm365: active  people 48 (12 members) · groups 9 · calendars 12 · events 311Resource  Cursors  Last synced       Backfilling  Failingusers     1        2026-09-26 10:15  0            0groups    1        2026-09-26 10:15  0            0calendar  12       2026-09-26 10:15  0            0

One consent, then app-only delta sync

You register one multi-tenant app in Microsoft Entra for your whole deployment and set its two secrets. A customer's admin opens Settings → Connections, clicks Connect, consents on Microsoft's own screen, and is sent back. The callback is the one route in the plugin with no session behind it, so it trusts nothing but a signed, expiring token your app minted a moment earlier — that token is what says which organisation the consent belongs to.

From then on nobody has to be signed in. Every 15 minutes a scheduled task queues a sync for each connected organisation, and each resource — users, groups with their memberships, each member's calendar from 30 days back to 90 ahead — resumes from Microsoft's own change token rather than reading everything again. A claim row stops two runs syncing the same thing at once, a throttled call waits exactly as long as Microsoft asks, and an expired change token starts a full pass.

Why the admin, not each person. One consent brings in the whole directory, so every member of an organisation arrives connected on day one instead of one at a time. It is also what Microsoft's default policy now demands: ordinary users can no longer consent to an app reading their mail, calendars or files, so a per-person flow would stop at an admin anyway.

Setup your coding agent drives

Registering an Entra app is about ten portal screens, so the connectors plugin ships a skill that does it for you. Ask your coding agent to run connectors: it checks what is already configured, then drives the Azure CLI to register the multi-tenant app, add its redirect address and its three read-only permissions, and create a client secret — which goes straight into your local settings or your deployment's secrets without ever being printed. You sign in to Azure yourself, and the agent stops for your go-ahead before it changes anything. Publisher verification, which Microsoft asks for before you sell to other organisations, needs a partner account the agent cannot create; the skill explains the steps instead.

The same skill covers the rest of the road: an organisation that registers its own app instead of using yours, the consent step and how to check the first sync with rocketflare connectors status, and a table that turns each Microsoft sign-in error code into its fix. Settings → Connections follows the same split: your platform's own admins see the deployment setup, a customer's admin sees only the consent step — or, when the deployment's app is not set up yet, a note to ask the operator and the option to use their own app — and members see the status and nothing to press.

Inside one organisation, people still see only their own

Every synced row carries the organisation, like everything else in the kit. That is not enough on its own: an organisation-wide sync pulls in everyone's calendar, and keeping tenants apart does nothing to stop one colleague reading another's. So each event is matched to the member it belongs to by email, a member's list only ever shows their own, and admins see everyone's. People in the directory who are not members of your app are listed there, but their calendars are never read.

What exists today, and what is designed next

Phase one is Microsoft 365's directory and calendars, polled. The design for the rest is written down: Google Workspace as a second provider on the same interface, webhooks that only ever trigger a sync with polling kept as the backstop, mail and files into the knowledge base with each item visible to its owner, and a person connecting their own account once an admin has allowed it. None of those is built yet.

The kit's part is four general-purpose seams any plugin can use: public routes under /api/hooks/<plugin id>, signed round-trip state, feature-flag checks from background work, and knowledge ingested by its upstream id so a re-sync updates a document rather than duplicating it. The design has the operator's and the customer admin's setup, step by step.