Microsoft 365 and Outlook Calendar

On the Microsoft side sits a work or school account in Microsoft 365, or a consumer Outlook account. Behind it are an Exchange Online mailbox and a calendar, both reached through the Microsoft Graph API: calendar events with attendees and response status, free/busy information, mail folders and messages, and the conversation identifiers that let a reply be threaded to the message it answers. Tenant-level policy sits above all of it, which is the difference that matters compared with a personal account.

On the AppBO side sit the same two consumers as any calendar and email connection: the booking calendar that needs to know when someone is genuinely busy, and the outbound email channel that needs a legitimate from-address and somewhere for replies to land. Wiring Microsoft in gives a Microsoft-based team one source of truth for their day and one address their clients already recognize, without asking them to live in a second inbox.

The practical reason to choose this over a generic SMTP relay is threading and visibility. Because the platform talks to the mailbox rather than to a relay, a sent message can appear in the user's own Sent Items and a reply can be read back and attached to the contact's conversation. The practical reason to be careful is the tenant: conditional access, app-consent policies and mailbox restrictions are all set by an administrator, so a connection that works for one user can fail for the next for reasons invisible inside the platform.

1. Establish which Microsoft account each user will connect, and whether it is a work or school account in a managed tenant or a consumer Outlook account. The two behave differently and the troubleshooting paths diverge immediately.
2. For a managed tenant, speak to the administrator before the first user tries. Ask whether user consent to third-party applications is permitted, whether an admin-consent workflow is in place, and whether conditional access policies restrict sign-in by location, device compliance or multi-factor state.
3. Confirm the mailbox is a real licensed mailbox rather than a shared mailbox or distribution list. Shared mailboxes generally cannot complete a user-delegated authorization on their own; a licensed user with delegated access is connected instead.
4. Check the user's time zone and working hours in both Outlook and their AppBO user profile, and make them agree before testing anything.
5. In the sub-account, open the integrations or calendar settings area and start the Microsoft connection. Where the platform offers separate calendar and email connections for Microsoft, decide which you need; connecting the calendar does not automatically give you sending.
6. Complete the Microsoft sign-in and consent screen as that user. Read the permissions listed on the consent screen itself. It is the authoritative list for the version of the application you are authorizing, and Graph permission names change over time.
7. If consent is blocked, note the exact error identifier Microsoft returns and give it to the administrator. Admin consent is granted in the tenant's enterprise applications area; the platform cannot grant it for them.
8. Choose which Outlook calendars are read for conflicts, including any secondary calendar the person actually uses. Select the single calendar the platform writes bookings to.
9. Configure the sending side if you connected the mailbox: the from-name, the reply-to behavior, and whether sent messages should be written into the user's Sent Items.
10. Decide how replies are handled. Reading replies back into the platform conversation requires mail read permission; confirm the consent screen granted it, and confirm with the user that they are comfortable with it.
11. Set up the booking calendar as normal (slot length, working hours, buffers, minimum notice, caps) and attach the connected user.
12. Verify the read direction by creating an event in Outlook over an offered slot and confirming the booking page stops offering it.
13. Verify the write direction by booking a test appointment and confirming it appears in Outlook with the right time, time zone and attendee list.
14. Verify sending by emailing a test contact from the platform, then checking that the message arrived, that the from-address is the Microsoft address, that it appears in Sent Items if configured, and that headers show it authenticated as expected.
15. Verify reply ingestion by replying to the test message from the contact's mailbox and confirming the reply appears in the platform conversation threaded to the original.
16. Record the connected account, the date and whether admin consent was involved, then remove the test data.

Platform to Microsoft

• Calendar events for appointments booked through a connected booking calendar, written to the one chosen Outlook calendar.
• Event subject, body, start and end with time zone, location or meeting link, and the contact as an attendee where configured.
• Event updates and cancellations when the appointment is rescheduled or canceled in the platform.
• Outbound email messages, with subject, HTML body, attachments and any reply-to override.
• A copy of each sent message into Sent Items, where that option is enabled.
• Threading headers on replies the platform sends, so the message lands in the existing Outlook conversation rather than starting a new one.

Microsoft to the platform

• Free/busy intervals from the selected calendars, which remove slots from booking pages.
• Changes to platform-created events made in Outlook: time moved, event deleted, attendee responses.
• Inbound replies to platform-sent messages, matched to the contact and attached to the conversation.
• Bounce and delivery-failure notifications that arrive in the mailbox as messages.
• The mailbox and calendar list, so you can choose what to read and write.

What does not move

• Historical calendar events or mail from before the connection. Nothing backfills.
• The whole inbox. Only messages the platform can associate with its own conversations are ingested; unrelated mail stays in Outlook.
• Contacts and distribution lists. The Outlook address book is not a CRM source and does not populate contacts.
• Teams chat, Planner tasks, SharePoint files and To Do items. None of these are in scope.
• Outlook categories, flags, rules and signatures. A signature configured in Outlook does not apply to platform-sent mail; set the signature in the platform.
• Outlook's own event reminders, which remain independent of platform reminders.
• Shared and room mailbox availability, unless a licensed user with delegated access is the connected account and the platform exposes that calendar.

Scenario: a Microsoft-based consultancy sends a proposal from the firm's mailbox, the client replies, and a follow-up call is booked into Outlook.

1. A consultant connects her Microsoft work account. The tenant administrator has already granted admin consent for the application, so her sign-in completes without a block.
2. She selects her primary Outlook calendar plus a shared delivery calendar for conflict checking, and her primary calendar as the write target.
3. An opportunity reaches the proposal stage and a workflow sends the proposal email. The platform sends it through her mailbox, so the client sees her firm address as the sender and a copy lands in her Sent Items.
4. The client replies two days later asking one question. Microsoft delivers the reply to her mailbox; the platform reads it, matches the sender to the contact, and attaches it to the existing conversation.
5. A workflow triggered by the inbound reply removes the contact from the chase-up sequence and raises a task for the consultant.
6. She answers from the platform conversation. The reply carries the threading headers of the original, so it appears in the client's existing thread rather than as a new message, and again lands in Sent Items.
7. Her answer includes the booking link for a thirty-minute follow-up call.
8. The client opens the booking page. The platform queries free/busy for both her primary and the shared delivery calendar; a delivery workshop on Tuesday afternoon blocks those slots.
9. The client books Wednesday at nine. The platform creates the appointment, assigns it to the consultant, and writes an Outlook event with the client's name in the subject, the opportunity link in the body, and the client as an attendee.
10. Outlook sends its meeting invitation; the client accepts, and the response status appears on the event.
11. The platform sends its own branded confirmation and schedules a reminder for the morning of the call.
12. On Tuesday evening the consultant moves the Wednesday call an hour later in Outlook. The change syncs back, the appointment time updates, and the reminder recalculates against the new start.
13. The call takes place. She marks the appointment outcome in the platform, and a workflow advances the opportunity and schedules the proposal-decision follow-up.

Rate limiting

Microsoft Graph throttles per application, per user and per mailbox, and Exchange Online applies its own sending limits per mailbox over rolling windows. Those limits make a connected mailbox unsuitable for bulk marketing sending regardless of what the platform will let you queue. Microsoft publishes current throttling guidance and service limits in its documentation; check those figures before planning volume rather than discovering them through failures. When throttled, Graph returns a retry-after indication, and a well-behaved integration waits rather than retrying immediately.

Retries and idempotency

Transient throttling and timeouts are retried, and a retry after an ambiguous timeout is where duplicates come from. Two events for one booking, or the same message sent twice. If you call Graph yourself rather than relying on the native connection, carry your own identifier for each logical operation and check before creating. In workflows, anchor on the appointment or the inbound-reply event and guard the branch with a tag so a replayed trigger does not re-send.

Field-mapping traps

Time zones are expressed explicitly in Graph and Outlook stores a user's preferred zone separately from the event's; a mismatch with the platform user profile produces events an hour or several hours out, and daylight-saving transitions are where it shows. Verify with a real booking across a transition if your business spans one. The from-address is the mailbox, not whatever you type in a template, so a template with a hard-coded sender will be overridden. Reply-to behavior differs between a user mailbox send and a relay send, so confirm which address replies actually reach.

Duplicate creation

Duplicate events appear when the write-target calendar is also read for conflicts, when two platform calendars target the same Outlook calendar, or when the user has a mailbox rule that copies events. Duplicate contacts appear when a reply arrives from an alias of an address already on file; Microsoft users commonly have several proxy addresses, so normalize and match on all known addresses rather than only the primary one.

Sandbox versus live

A Microsoft developer tenant is the closest thing to a sandbox, and it is genuinely useful for proving the consent flow without touching production policy. It will not reproduce the customer's conditional access rules, so a connection proven in a developer tenant can still fail in theirs. Test the consent path in the real tenant with one pilot user before rolling out.

Authentication expiry

Refresh tokens are revoked by a password change, by an administrator revoking sessions, by conditional-access re-evaluation, by removing the application from enterprise applications, and by the user themselves in their account's app permissions. Multi-factor policy changes are a frequent silent cause. The failure mode is quiet: bookings keep being offered while conflicts stop being read, and outbound mail queues or falls back to another sender. Monitor connection status per user and treat a reconnect as routine maintenance.

What commonly breaks

• Admin consent never granted, so every user sees a block that looks like a platform fault.
• Conditional access requiring a compliant device, which the platform's server-side calls cannot satisfy.
• A shared or room mailbox connected directly, which cannot complete user-delegated consent.
• Mailbox sending limits hit by a marketing campaign routed through a user mailbox instead of a dedicated sending domain.
• Outlook rules moving platform mail out of the folder the platform reads, so replies never appear in the conversation.
• The Outlook signature being added by the client application on manual sends but absent on platform sends, giving two different-looking emails from one person.
• A license removed from a departing user, which kills both calendar and sending with no notice inside the platform.