Plan Outlook Calendar around Graph identity and recovery

The target Microsoft Graph connector covers calendars, events, attendees, availability, event CRUD, and created/updated/deleted events. No Outlook Calendar method is implemented or released.

Illustrative product surface. The workflows below are planned, not a live connector.

Talk to us ↗Read technical guides →

Capability boundary

Outlook Calendar is a planned official-API connector

The catalog records target Graph resources and methods. Microsoft application registration, tenant consent, subscription renewal, real-account behavior, and production conformance remain open.

Catalog status and access: Outlook Calendar — planned, official api
Authentication: A customer Microsoft application must authorize the exact user, tenant, and delegated calendar scopes. Administrative or shared-calendar access requires separate authority and cannot be inferred from mailbox access.
Resources: calendars, events, attendees, availability
Target actions: calendar.list, event.list, event.get, event.create, event.update, event.delete
Target events: calendar.event.created, calendar.event.updated, calendar.event.deleted
Limitations and failures: No Graph Calendar method is implemented; Online-meeting creation, recurrence handling, attendee-response actions, and normalized change delivery lack conformance evidence; Tenant policy and subscription renewal remain provider-specific
Release gates: Outlook Calendar — Microsoft application registration, tenant consent, and subscription renewal

Calendar ownership

Identify the tenant, user, calendar, and acting account

A planned command must name the connected account and provider calendar explicitly. A visible calendar name or email address is not enough to establish write authority across personal, organizational, delegated, or shared calendars.

Event model

Preserve Graph IDs and time context

The normalized resource should retain Graph event and calendar identifiers, organizer and attendee state, time-zone context, cancellation state, and raw metadata needed for provider-specific updates or support.

Writes

Use concurrency and durable intent for changes

Create, update, and delete operations need account-scoped permissions, stable command intent, and provider version context where available. A timeout remains uncertain until DewEngine can read or otherwise reconcile the provider result.

Availability

Keep free/busy separate from event details

The target availability resource should return only the scheduling information the authorized account may see. Booking policy, working hours, buffers, and conflict decisions remain the calling product's responsibility.

Synchronization

Renew notifications and reconcile provider state

A production connector needs a bounded baseline, provider-native incremental state, renewable subscriptions, deletion handling, and recovery after gaps. None of that behavior is implemented or proven by the current target event list.

Illustrative contract

Preview the intended integration boundary.

This shape documents the intended account and resource boundary. It is not callable, and it does not generate provider traffic.

Explicit connected-account ownership
Stable public resource identifiers
Truthful provider outcome state
Release status beside every capability

Illustrative shapePlanned · not callable

const unreleasedContract = {
  resource: "message",
  account_id: "acc_example",
  provider: "target_provider",
  availability: "not_implemented"
} as const;

No live connector · no provider request

Questions

Before you build.

Can DewEngine create an Outlook Calendar event today?+

No. The entire Outlook Calendar connector remains planned.

Are Teams links and recurring meetings supported?+

No support claim is made. Those behaviors require explicit catalog coverage and real-account conformance before they can be promised.

Build with us

Does this match the workflow your users need?

DewEngine is in development. Real use cases decide what ships first.

Share your use case ↗