Exchange Online EWS Disablement: Protect CRM Outlook Sync Before the October 2026 Cutoff

Here is what the guide gets right, where it goes too far, and what admins should check.

The three failure points​

The Nutshell guide opens with a statistic from Salesforce's 2025 State of Data and Analytics report: businesses use an average of 897 applications, and only 29% of them are connected. Salesforce's report traces that figure to MuleSoft's January 2025 Connectivity Benchmark. It shows how fragmented business software is. It does not measure how often CRM integrations fail.

The guide's three problem areas are:

1. Outlook sync: emails, contacts or calendar items that don't reach the CRM. Salespeople usually notice missing email first.
2. Excel round-trips: data exported, edited and re-imported without being matched to existing records, which creates duplicates.
3. Teams and SharePoint permissions: access that drifts away from what admins intended. It often goes unnoticed until someone finds they have lost, or gained, access to a deal.

Keep the source in mind. Nutshell sells a CRM, and its advice ends with "make the CRM the single source of truth." That advice is reasonable, but it also suits the author. The guide's claims that problems fall into these areas "nine times out of ten" and are "almost always preventable" come with no incident data. Read them as opinion.

Outlook sync: the Exchange limits are different things​

The guide says many users don't know about two Exchange Online limits: 3,600 messages per hour per mailbox, and 100 ActiveSync devices per mailbox. It suggests a CRM can hit these limits and trigger sync errors and bounced mail. Both numbers appear in Microsoft's Exchange Online limits documentation. Neither one means what the guide implies.

• The 3,600 figure is a receiving limit. Microsoft counts messages arriving at a mailbox from all sources in an hour. Once the limit is hit, mail from the internet or on-premises senders bounces with a non-delivery report. Mail from internal senders still counts toward the limit but is not blocked. The limit resets after an hour. It is not a cap on how often a CRM connector can read a mailbox.
• The 100-device figure is an Exchange ActiveSync limit. It covers mobile devices paired with a mailbox, not CRM API traffic.
• API throttling is a separate system. Microsoft's EWS throttling documentation describes limits on concurrent connections, subscriptions, batch sizes and processing time. In Exchange Online, customers can't see or change those settings, and the values differ from on-premises Exchange. The guide advises setting integrations to "run in line with" the default throttling policies. The practical version is simpler: build the connector to stay under limits you can't adjust.

The guide's core advice to use incremental sync is sound. Microsoft's EWS sync guidance says the first sync pulls everything and later syncs fetch only what changed, using a stored sync state. Microsoft also recommends that developers:

• request only item IDs rather than full property sets when checking for changes
• avoid fetching every changed item in full; a read/unread change needs only a flag update
• keep batches small (Microsoft suggests 10 items when retrieving item details)
• avoid bursts of requests
• stop sending requests when throttled and wait out the back-off period, because retrying makes recovery slower

How to troubleshoot a broken Outlook-to-CRM sync​

1. Find out how the connector talks to Exchange. Ask the vendor whether it uses EWS, Microsoft Graph or something else. Everything else depends on the answer.
2. Record the exact error and when it happened. A non-delivery report, an HTTP throttling response and an authentication failure are three different problems.
3. Check the Mailboxes exceeding receiving limits report if mail is bouncing. Microsoft provides it for mailboxes receiving unusually high volumes.
4. Rule out authentication and consent problems before blaming throttling. Expired app consent or changed permissions can look just like a sync failure.
5. Ask the vendor whether the connector uses change-based sync. If it re-reads whole mailboxes on every cycle, that needs fixing.

The deadline the guide leaves out: EWS shuts down tomorrow​

This is the most important point, and the Nutshell guide doesn't mention it. Microsoft's deprecation page says it announced that EWS will be disabled in Exchange Online in October 2026. Its timeline says that in October 2026: EWS starts to be disabled globally for all organizations. Final shutdown is scheduled for April 2027.

The Exchange team's February 2026 blog post described a phased, admin controllable disablement plan that starts in October 2026 and concludes with a complete shutdown of EWS in 2027. The key mechanism: Any tenant with EWSEnabled still set to Null on October 1, 2026, will see the value changed to False as the deployment rolls out. That will block EWS for all applications in the tenant at that time.

Tenants had until today to opt out of the automatic change. Microsoft said that if you proactively configure an AppID Allow List and set EWSEnabled to True by the end of September 2026, your tenant will be excluded from the October 1 automatic change. Microsoft also said it will pre-populate the AppID Allow List for customers who have not created one, based on each tenants own usage. If you miss the window, there is still a way back: the admin can re-enable EWS (by setting EWSEnabled to True) after we block it. Microsoft warns that there will be a service interruption in this case.

Some practical details:

• Replacing the allow list overwrites it. Atriomail's MSP checklist, citing Microsoft message center posts, notes that setting the list replaces the existing one, so every required App ID has to go in at once, and changes can take up to 24 hours to apply.
• On-premises Exchange isn't affected. Iron-Core's summary says that Microsoft says EWS in on-premises Exchange Server is not part of this retirement.
• Microsoft's own apps are affected too. Microsoft says the Midnight Blizzard incident widened the effort to its own products. It lists Outlook, Office, Teams and Dynamics 365 among those it is working diligently to remove EWS dependencies from.

What does this mean for CRM integrations? If your Outlook-to-CRM connector still uses EWS, the next sync failure may not be a throttling problem or a bad import. It may be the tenant blocking EWS on schedule. Not every Outlook integration uses EWS, so check before assuming. Microsoft's EWS Usage Reports are the place to start, followed by a direct question to the CRM vendor about its migration to Microsoft Graph.

Excel: the duplicate problem is real, but the survey doesn't measure it​

The guide's explanation of Excel duplicates is correct. Someone exports records, edits them offline, then re-imports them without matching against existing records. The CRM ends up with two versions of the same contact, or the import overwrites newer data with old values.

The supporting statistic needs a closer look. The guide cites Ledge's 2025 study, and Ledge's own write-up confirms that 94% of the finance teams it surveyed use Excel in month-end close. Ledge also says 50% of respondents named Excel as a reason the close is slow, with cash reconciliation as the main bottleneck. The guide rewords that as time spent matching Excel data with other systems, which is close but not identical. Ledge sells reconciliation automation, and its survey covered finance teams in high-transaction businesses. It says nothing about how often CRM duplicates occur.

Practical safeguards, based on general data-management practice rather than any Microsoft requirement:

• Decide which system owns each field. "The CRM owns everything" is simple, but some fields may belong to ERP or finance systems.
• Match on stable IDs, such as the CRM record ID, not names. "Jon Smith" and "Jonathan Smith" at the same company will get through name-based matching.
• Test the import on a small sample and check the tool's create, update and skip rules before a full run.
• Treat exports as temporary. A spreadsheet from last Tuesday should not become an unofficial second CRM.
• Keep a rollback path, such as an audit log, a backup, or at least a copy of the file you imported.

Teams and SharePoint: the guide overstates the problem​

This section needs the biggest correction. The guide says that when someone shares a single file or folder externally, later SharePoint permission changes apply to everything except that item. That is the right general idea, but it describes the mechanism loosely.

Microsoft's documentation on permission scopes explains how it works. Files and folders inherit permissions from their parent by default. Sharing a file or folder breaks that inheritance and gives the item its own permission list. From then on, the item's access can differ from its parent's. Sharing one item doesn't change any other items. The risk is that the shared item stops following changes made at the parent level. Microsoft also notes that SharePoint does not tidy this up automatically. Moving individually shared files into a folder later does not restore inheritance.

How Teams channels map to SharePoint also matters:

• Standard channels share the team's SharePoint site, with one folder per channel. Microsoft recommends managing access through Teams rather than sharing the site directly.
• Private and shared channels each get their own SharePoint site. Site membership comes from the channel and can't be managed separately in SharePoint.
• Shared channels have an offboarding gap. Microsoft's shared channels documentation says that if someone was given access to a file, folder or notebook through SharePoint, that access can remain after they are removed from the team or channel.

The guide cites Varonis's 2025 State of Data Security report to back up the risk. Varonis says it examined nearly 10 billion cloud resources across 1,000 organizations and found that 88% had "ghost users": stale accounts that are still enabled. That is a real concern, but it measures stale accounts in general, not Teams permission mismatches in particular.

The guide also says managing access through Microsoft 365 Groups will "eliminate the potential for a permission mismatch." That goes too far. Groups make membership easier to manage, but they don't remove unique permissions already set on individual files, and they don't cover every external-sharing case.

Access review checklist​

1. Review team and channel membership, focusing on private and shared channels.
2. Audit external sharing links and remove or expire any that are no longer needed.
3. Find files and folders with unique permissions and decide whether each one needs them.
4. During offboarding, check item-level grants as well as group membership, especially in shared channels.
5. Share folders rather than individual files where possible. Microsoft recommends this to keep the number of unique permission scopes down.
6. Repeat the review on a schedule. Permission drift is gradual and easy to miss.

Verdict: good list, loose details​

The Nutshell guide is right about where CRM–Microsoft 365 integrations tend to break. Its process advice is also sound: pick a system of record, sync in small increments, test with real data, make someone responsible for the sync error logs, and review permissions regularly. Organizations that don't clearly own their integrations will run into these problems.

The technical explanations are where it falls short. It treats a mail-receiving limit as an API throttle, overstates how SharePoint sharing affects other items, and uses vendor surveys that don't measure what they are cited for. Most importantly, it doesn't mention the EWS retirement, which starts tomorrow and could affect every EWS-based Outlook connector in a tenant.

If you do one thing today, find out which protocol your CRM's Outlook connector uses. If it uses EWS and you haven't set up an allow list, expect sync failures starting tomorrow.