Microsoft authorization
Present the supported authorization route in a named workspace and project rather than making customers handle integration credentials in the product UI.
Microsoft mailbox architecture
Keep Microsoft mailbox state understandable after the connection succeeds.
Give a product team a durable view of customer consent, tenant-aware mailbox context, event delivery, and the exact path to recover a degraded connection.
Email connection architecture
Set up Outlook with a clear product boundary.
Make account ownership, project context, health state, and recovery visible to the customer instead of burying the integration behind an opaque setup step.
Tenant-aware operational state
Keep mailbox health, reconnection status, and recovery instructions attached to the specific customer account.
The product workflow
Outlook should be visible in the product, not hidden behind a connection status.
Explore the original Moira surfaces for the path from a customer-controlled connection to an observable workflow, with capability and recovery context alongside it.
1 of 3
Connection control plane
Give the customer a real surface for operating Outlook.
Moira keeps connected-account health, project-scoped credentials, delivery evidence, and a safe recovery route together in the customer console.
Explore the product
Use cases
Outlook product use cases
Use the provider as part of an ATS, CRM, or outreach workflow while retaining project and capability context at every step.
MMaya ChenConnection context updated
DDaan BakkerHealth state needs review
AAmara SinghProject event observed
ATS publisher
Keep Outlook connection context beside candidates, account health, and recruiter-owned recovery actions.
Explore use caseMMaya ChenConnection context updated
DDaan BakkerHealth state needs review
AAmara SinghProject event observed
CRM publisher
Put Outlook activity alongside the customer record so account teams can investigate the next safe action.
Explore use caseMMaya ChenConnection context updated
DDaan BakkerHealth state needs review
AAmara SinghProject event observed
Outreach publisher
Make Outlook a visible, policy-aware stage in a controlled multi-step outreach workflow.
Explore use caseDeveloper integration
Make the Outlook event contract explicit before it drives an action.
Associate each signal with a project, account, provider state, and recovery path. The result is an operable integration rather than a disconnected API response.
Read developer documentationconst event = await moira.events.verify({
projectId, provider: "outlook",
eventId: request.headers.get("x-moira-event-id"),
});
if (event.state === "attention_required") {
await queueRecoveryReview(event);
}Trust work in progress
Security and compliance status
These are current in-progress programs, not completed certifications, compliance guarantees, or a substitute for your own assessment.
Integration questions
Outlook integration FAQ
Answers describe product boundaries and operational recovery without making provider capability promises.
How does a Outlook connection begin?
A workspace member begins in the intended project context. Moira presents only the connection path and account state that the live provider registry and workspace policy permit.
Does this page guarantee a Outlook capability?
No. The page describes an integration architecture. Actual availability remains subject to configured provider paths, account state, entitlement, project policy, and provider terms at the time of use.
How does the customer recover a degraded connection?
The customer console is designed to present account health, the specific recovery route, and the relevant project context. Operators should follow that route rather than retrying a blind action.
How are events and delivery outcomes represented?
Moira keeps provider outcomes and event references available beside the workflow so a product can distinguish requested, observed, and attention-required states.
What data boundary applies to this provider?
Microsoft mailbox state is projected into the selected Moira workspace and project. Provider credentials, client secrets, and service assertions are never presented in the public page or browser surface.
How are webhooks and retries handled?
Event-oriented integrations should retain an identifier, delivery boundary, and retry context. Downstream systems should decide on recovery from evidence instead of replaying an uncertain operation.
What is Moira’s current security and privacy posture?
Moira is progressing through a SOC 2 Type II audit and an ISO 27001 certification program, while operating a GDPR-focused privacy program. These are in-progress initiatives, not completed certifications or a guarantee of suitability for a particular use case.
Where should an engineering team start?
Start by defining project scope, the customer-owned connection path, event contract, and recovery model. Then use the customer console and developer documentation to check live readiness.
Provider path
How the provider path stays operable
A useful integration does not stop at authorization. It makes the current boundary, account state, and recovery route legible inside your product.
Outlook workflowIllustrative
- Make mailbox organization visible to the owning workflow
A customer can understand which account is connected and whether the operational state needs review without inspecting provider configuration.
- Use event evidence to drive product decisions
Treat delivery and account signals as explicit inputs to a workflow, with replay and recovery handled through observable operations.
- Show what a Microsoft connection needs next
When a customer connection degrades, offer a precise reconnect or support route rather than a generic failure message.
Start with the right boundary
Connection modes
Microsoft authorization
Present the supported authorization route in a named workspace and project rather than making customers handle integration credentials in the product UI.
Tenant-aware operational state
Keep mailbox health, reconnection status, and recovery instructions attached to the specific customer account.
Product workflows
From connection to an operable outcome
Inbox and folder state
Make mailbox organization visible to the owning workflow
A customer can understand which account is connected and whether the operational state needs review without inspecting provider configuration.- Account-context presentation
- Scoped mailbox state
- Operational support trail
OutlookContextEvents
01
Connected account context attached
02
Workflow event ready for review
03
Recovery state is visible
Event delivery
Use event evidence to drive product decisions
Treat delivery and account signals as explicit inputs to a workflow, with replay and recovery handled through observable operations.- Normalized event references
- Webhook status
- Retry-aware diagnostics
Outlook event stream
Account state projected
evt_01Event envelope received
evt_02Delivery evidence recorded
evt_03Consent recovery
Show what a Microsoft connection needs next
When a customer connection degrades, offer a precise reconnect or support route rather than a generic failure message.- Tenant-aware recovery
- Clear ownership
- No browser secret handling
Outlook account Health visible
Connection stateObserved
Project boundaryScoped
Recovery routeReady
Capability boundaries
Capability map
Every category communicates its readiness state in words, not colour alone.
Connection health
- Hosted authorization state
- Account-health projection
- Recovery guidance
Mailbox workflows
- Tenant-aware workflow selection
- Configured email operations
- Provider-policy boundary
Operational evidence
- Event references
- Signed webhook delivery
- Audit-ready account context
Build with context
Developer resources
Keep connection state, event evidence, and security boundaries in the implementation path from the start.
Outlook connection architectureStart with project context, the hosted connection route, and an explicit account-health state.Event delivery and recoveryUse signed webhook delivery, event identifiers, retries, and account state to make failures actionable.Connection security boundaryKeep credentials, provider consent, API-key scope, and project isolation separate from browser-visible code.
Data-handling boundaryMicrosoft mailbox state is projected into the selected Moira workspace and project. Provider credentials, client secrets, and service assertions are never presented in the public page or browser surface.
Architecture questions
Frequently asked questions
How does a Outlook connection start?
A workspace member initiates a connection in the intended project context. Moira presents only the authorization path and capability state that the control plane permits.
What happens when Microsoft consent, tenant policy, or connection health changes?
The account health and capability state becomes visible in the customer console. A customer or operator can follow the specific reconnect, approval, or policy-recovery route instead of retrying a blind action.
Is availability guaranteed by this page?
No. This page explains the integration architecture. The live provider registry, workspace policy, and provider terms decide whether a connection or action is available at execution time.
Start with verified readiness