Microsoft 365
Connect Outlook or shared mailboxes so Atlas can monitor operational email in Microsoft 365.
| Capability | Setup time | Auth mode |
|---|---|---|
| Read email, classify threads, draft replies | 20-30 min | Microsoft OAuth |
Prerequisites
| Requirement | Value |
|---|---|
| Microsoft role | Global admin or Exchange admin for tenant consent |
| Mailbox type | User mailbox or shared mailbox |
| Permissions | Mail read access and send access when enabled |
Connect in Atlas
Use this flow when Microsoft 365 mailbox access is enabled for the workspace.
Atlas → Connectors → Microsoft 365
| Item | Detail |
|---|---|
| Consent owner | A Microsoft tenant admin such as admin@acme.com who can grant Graph mail permissions. |
| Tenant example | Acme Manufacturing Microsoft Entra tenant, not a personal Microsoft account. |
| Mailbox target | ops@acme.com, ar@acme.com, or a shared mailbox Atlas should monitor. |
| Atlas result | A connected Microsoft 365 row with tenant, mailbox, status, and management actions. |
| Current fallback | If the Microsoft 365 mailbox connector is not enabled in your workspace yet, connect Gmail for email intake and use Microsoft 365 only for approved pilot setup. |
Primary action: Connect Microsoft 365.
- Open the Microsoft 365 connector — In Atlas, go to Connectors and select Microsoft 365 when it is available for your workspace.
- Choose the mailbox scope — Use a stable operations mailbox whenever possible. For shared mailboxes, confirm the admin understands which mailbox Atlas will access.
- Complete Microsoft consent — Sign in with the correct Microsoft tenant and grant the requested Graph permissions. Admin consent is usually required for shared or tenant-managed mailbox access.
- Verify in Atlas — Return to Atlas and confirm the connected tenant and mailbox before enabling workflow intake.
Shared mailboxes
For operations teams, shared mailboxes are usually cleaner than named-user mailboxes. They make ownership explicit and avoid tying automation to one employee account.
Recommended
Use a stable address such as sales-ops@, purchasing@, or support@ when the workflow spans multiple operators.
Permissions
Microsoft 365 mail access is usually granted through Microsoft Graph. The exact permissions depend on whether Atlas monitors a user mailbox, a shared mailbox, or a tenant-wide operations mailbox.
| Requirement | Value |
|---|---|
| Read threads | Mail.Read or Mail.Read.Shared depending on mailbox ownership |
| Manage thread state | Mail.ReadWrite or Mail.ReadWrite.Shared when Atlas labels, archives, or updates messages |
| Send approved replies | Mail.Send or Mail.Send.Shared when policy allows external sends |
| Admin consent | Required for most tenant-wide application permissions and often preferred for shared mailbox rollout |
Application vs delegated access
Delegated access acts as a signed-in user. Application access can run without a user session and should be constrained to the mailboxes Atlas actually needs.
Microsoft setup references
- Microsoft Graph mail permissions — Use this to validate Mail.Read, Mail.ReadWrite, and Mail.Send permission choices before granting tenant consent.
- Review Microsoft Entra app consent — Use this when an admin needs to inspect or approve the consent request for a tenant-managed application.
Verify the connection
- Confirm tenant and mailbox — Check the Microsoft tenant, mailbox address, and shared mailbox selection before enabling workflow intake.
- Validate admin consent — If Atlas cannot read a shared mailbox after OAuth succeeds, check that the Enterprise Application has the required Graph permissions and admin consent.
- Send a test thread — Send a realistic customer request and confirm Atlas can read the thread, sender, recipients, and body.
- Test send policy separately — If send permissions are enabled, verify drafts and sends follow Atlas approval policy before production rollout.