OnSched 3.15.0 - enterprise Outlook tenant connections

Enterprise Outlook setup

• One administrator consent: Create a Company Microsoft tenant connection and open its returned adminConsentUrl. Owners and admins can start the same flow from Company Settings → Outlook in the dashboard; that tab is hidden for User and Resource roles. OnSched activates the connection only after redeeming Microsoft's authorization code and verifying Calendars.ReadWrite application permission in that token's tenant. A Microsoft tenant can belong to only one Company.
• Mailbox connect in the dashboard: After a tenant connection is ACTIVE, owners and admins can submit one existing Resource email from that same Outlook tab. Existing delegated Outlook connections are skipped, not replaced.
• Initial lists and later one-offs use one endpoint: Send each existing Resource email to POST /v3/externalCalendarTenantConnection/{id}/mailboxConnection. The request selects the writable default Outlook calendar and completes an initial 30-day sync before returning success.
• Safe retries: Repeating a mailbox request reverifies and resynchronizes the same connection. Omitting an email never disconnects it.
• Throttle-aware loops: Microsoft Graph throttling returns 429 with Retry-After, so setup scripts can pause and retry the same email.
• Delegated OAuth remains compatible: Existing per-Resource Outlook connections are skipped with ALREADY_CONNECTED, not replaced.
• Explicit cleanup: Disconnect Resource calendars, or delete the Resource, before deleting their tenant connection. In-use tenant connections return 409.
• Retried admin-consent callback: A duplicate Microsoft redirect after a successful activation no longer marks that tenant connection FAILED. A leftover failed row for the same Company tenant is replaced by the newly verified connection instead of being returned as success.

Microsoft's tenant-wide application permission authorizes every mailbox in the consenting tenant. OnSched accesses only mailboxes explicitly submitted to the mailbox-connection endpoint. See External Calendar Sync.

Resource calendar account ownership

• Resources connect one Google or Outlook account and one authorization mode, including pending setup. Existing personal connections are preserved when organization consent is granted. This release copies existing calendar credentials onto Resource during an additive schema migration and stores new credentials only on Resource. Existing calendar selections are preserved; if legacy accounts conflict, one usable integration is retained and another account can be reconnected explicitly.
• Disconnect also prevents an in-flight padding sync from restoring retired event mappings; appointment operations skip stale disconnected calendar snapshots.
• Same-account reauthorization preserves calendar IDs and read/write selections. Stale OAuth URLs cannot replace the connection.
• Organization-connected Resources display their bound mailbox and default-calendar read/write toggles. Owners and admins can connect an unconnected Resource through an approved tenant directly from Resource settings. The organization picker labels each option with the Company name, not the Microsoft tenant id.
• Selecting no calendars keeps authorization; deselected rows remain listed with disabled flags. Disconnect retires local event mappings and imported busy blocks, leaves remote appointment events untouched, and does not copy existing appointments to a replacement account.
• Compatibility exception: Calendar and nested Resource responses no longer return refresh tokens or provider account credential identifiers. Clients must not rely on these fields. Existing routes and non-secret connection fields remain available.

Calendar sync reliability

• Distinct busy per calendar: When a Resource reads two calendars, the same provider event ID can exist as two distinct busy rows, one per calendar. Re-ingesting one calendar does not collapse the other.
• Resource DELETE and disconnect: Deleting a Resource or disconnecting its calendar clears local bindings, imported busy blocks, credentials, and tenant refs so DELETE /v3/externalCalendarTenantConnection/{id} can succeed. Remote appointment events stay on Google or Outlook.
• Write-calendar switch: After you change the write calendar, appointment event cleanup (cancel, reschedule, padding) still uses the calendar that originally received the event, including when that calendar is now read-only.
• Padding refresh: Concurrent padding refreshes on the same connected calendar do not leave extra remote padding events.
• Historical Google events: Some older Google events cannot be located after historical calendar switches. Those remote events stay untouched; OnSched does not guess the current write calendar as the origin.
• Responses: Internal origin metadata is omitted from appointment GET and list responses. Provider event IDs remain.
• Origin writes: Appointment create, update, reschedule, cancel, and confirm reject origin metadata in the request body. Cleanup uses only the origin OnSched stored when it created the provider event.
• Reauthorization writes: Same-account reauthorization does not pause appointment calendar creates while the existing token remains valid.
• Permanent delete: Deleting a hold or reserved appointment still deletes remote calendar events after local mappings cascade.