Plan Outlook mail with tenant-aware Graph state

The target Microsoft Graph connector covers messages, drafts, folders, attachments, contacts, mailbox actions, and received/updated/deleted events. It remains planned without application registration or real-account conformance.

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

Talk to us ↗Read technical guides →

Capability boundary

Outlook mail is a planned official-API connector

The catalog declares a target Microsoft Graph surface, not an implemented mailbox. Microsoft application registration, tenant consent, permission selection, synchronization, and production verification remain open.

Catalog status and access: Outlook mail — planned, official api
Authentication: A customer Microsoft application must choose the supported tenant audience and delegated access required for the user-owned mailbox. Administrative access and shared mailboxes require separate, explicit tenant authority.
Resources: mailboxes, threads, emails, drafts, folders, attachments, contacts
Target actions: email.list, email.get, email.send, email.update, email.delete, draft.create, folder.list
Target events: email.received, email.updated, email.deleted
Limitations and failures: No Graph mailbox method is implemented; Reply and move are not separate declared methods; Subscription renewal, per-folder delta, shared-mailbox access, and tenant policy need real-account evidence
Release gates: Outlook mail — Microsoft application registration, tenant consent, and production verification

Identity

Bind tenant, user, mailbox, and DewEngine account

The OAuth callback should establish the authenticated Microsoft subject and tenant before creating an account record. A mailbox address supplied by the browser is not sufficient proof of ownership or delegated access.

Folders and messages

Retain Graph identifiers beside normalized mail

Message, attachment, draft, and folder resources can share a common outer shape while keeping Graph message IDs, folder IDs, conversation identifiers, categories, and change metadata for provider-specific operations.

Incremental state

Track delta independently for each selected folder

A planned sync worker needs a baseline and opaque Graph delta state for every synchronized folder. It must apply all pages before committing the next checkpoint and reconcile moves or deletes across the folders in scope.

Sending

Report the provider result without inventing engagement

The target draft and send operations preserve the connected mailbox, recipients, content, attachments, and command intent. Provider acceptance is not evidence of final delivery, opening, clicking, or a reply.

Operations

Renew subscriptions and expose tenant-specific failures

Consent removal, conditional access, administrator policy, shared-mailbox rights, throttling, and expiring subscriptions need actionable states. A reconnect or admin-consent requirement should not be flattened into a transient send error.

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 synchronize Outlook mail today?+

No. The Graph connector is planned and has no provider methods or real-account evidence.

Are every consumer, organizational, and shared mailbox configuration guaranteed?+

No. Supported account types depend on the configured Microsoft application, selected permissions, tenant policy, and the exact real-account scenarios DewEngine has tested.

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 ↗