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.
| Question | Sign-in | A connection |
|---|---|---|
| Who grants it | the person signing in | the organisation's admin, once |
| What it reaches | that person's own profile | the directory, and the calendars of your app's members |
| The token | none kept in use | an app-only token per organisation, cached encrypted |
| The app behind it | the kit's sign-in client | a 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.
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.