The important detail is Microsoft’s explanation. It did not say the work was merely delayed or superseded by another automation interface. The company says AppleScript workflows vary too widely across organizations and depend on classic Outlook behaviors absent from the rebuilt client, making full compatibility infeasible. For Mac users and administrators who treated the roadmap date as a migration dependency, this is a permanent product decision rather than another missed delivery window.
Microsoft’s current roadmap notice offers an apology, but it offers no replacement feature, migration guide, compatibility matrix, or supported subset of AppleScript commands. That omission leaves organizations responsible for determining which mail, calendar, filing, document-routing, and message-generation processes will fail when users move to the new client.
A five-year roadmap item ends without a compatibility layer
Microsoft originally published Roadmap ID 88537 on December 8, 2021. The archived roadmap record still shows the earlier commitment in direct language: Microsoft would add AppleScript support to the new Outlook for Mac. As recently as February 2025, the item remained listed as in development, with a target of December 2025.
That schedule had already slipped by the time Microsoft finally cancelled it. Microsoft Q&A threads from 2024 and 2025 show users asking whether AppleScript was available in the new Mac client and being directed back to the same roadmap item and its anticipated date. Those support discussions were not a release guarantee, but they document a recurring practical expectation: customers delayed decisions or maintained the legacy client because they believed a native automation path was still coming.
The cancellation confirms that Outlook’s new Mac architecture will not recreate the scripting surface many users had in the older application. Microsoft has not published a list of unsupported legacy commands, object classes, or events. It has instead concluded that the breadth of existing scripts makes meaningful general compatibility unworkable.
That conclusion may be technically understandable, but it is operationally incomplete. A customer cannot assess risk from “workflows vary widely.” An IT team needs to know whether selected messages can be read, a draft can be created, a category can be assigned, a rule can launch an action, attachments can be exported, or a calendar item can be generated. Microsoft has provided none of that mapping because the planned feature itself is gone.
The impact falls on locally built mail workflows
AppleScript is not equivalent to a keyboard shortcut or a simple macro. On macOS, it is often the glue between applications: a script can act on the selected Outlook message, create a task or document, rename and store attachments, hand structured data to a business system, or prepare a reply from a local template. Many such workflows were created outside central IT, then became part of a department’s daily process.
Microsoft acknowledged in its cancellation note that these patterns rely on classic-client behaviors that do not exist in the new Outlook. That is a more consequential admission than a conventional “feature unavailable” label. It means a script may not merely need a small syntax update; it may need to be redesigned around a different trigger, data model, authentication flow, and deployment model.
The new Outlook for Mac did not support the same AppleScript behavior from its earliest releases. In a Microsoft Q&A response from January 2021, support staff advised a customer that retrieving selected messages through AppleScript did not work in the new Outlook experience and suggested switching back to the existing client. The eventual roadmap commitment appeared to offer a route out of that gap. The August 2026 cancellation removes it.
This affects individual users, but the harder problem belongs to managed environments. An organization may not know it has an Outlook AppleScript dependency until a user changes clients, upgrades Office, receives a new Mac, or loses access to a legacy-client fallback. Scripts may live in users’ home directories, Script Menu folders, Automator workflows, Shortcuts, keyboard automation tools, or shared departmental documentation rather than in source control.
Outlook add-ins can replace some workflows, not all of them
Microsoft’s supported strategic alternative is its Outlook add-in platform, which uses web technologies and Office.js rather than local AppleScript. Microsoft documents that Outlook add-ins can run on Outlook for Mac, the web, Windows, iOS, Android, and Outlook.com. For centrally managed organizations, that cross-client model can be a genuine advantage over a local script that only works on one user’s Mac.
Some automation scenarios are now possible through event-based Outlook add-ins. Microsoft’s developer documentation includes examples that run code when a user begins a new message or appointment, such as applying a signature or retrieving data through Microsoft Graph. That is useful for standardized, centrally deployed workflows such as signatures, classification, compliance prompts, recipient checks, or approved CRM integrations.
But an Outlook add-in is not a drop-in AppleScript replacement. Microsoft’s own documentation describes meaningful constraints: event-based add-ins need an internet connection, must be short-running, face timeout limits, and can be terminated if a user leaves the relevant mail item. Several automatic scenarios also require administrator deployment. On Mac, organizations using the newer unified Microsoft 365 manifest must maintain a separate add-in-only manifest for compatibility.
More importantly, an add-in works through the Outlook web API surface, not general-purpose control of local macOS applications and files. A script that takes a selected email, extracts attachment metadata, moves files through a local Finder workflow, invokes another native application, and updates a local database is not automatically expressible as an Outlook add-in. Rebuilding it may require a server component, Microsoft Graph permissions, a managed local helper, or a redesigned business process.
Microsoft has not said that its add-in platform covers the workflows whose diversity it cited as the reason for cancelling AppleScript support. Administrators should therefore treat add-ins as a possible engineering path for specific processes, not as a vendor-certified migration answer.
Legacy Outlook is a shrinking safety net
The immediate temptation will be to keep affected Mac users on legacy Outlook. That can buy time if the existing app, account type, Office license, and organizational configuration still permit it. It should not be mistaken for a durable remediation plan.
Microsoft’s own support pages continue to distinguish between legacy Outlook for Mac and the new experience, and the company has repeatedly moved Mac functionality toward the newer client and web add-ins. Microsoft also removed support for injection-based native plugins in Outlook for Mac beginning with version 16.89 in September 2024, pushing customers toward supported add-in models. The direction of travel has been clear even where exact client-transition timing has varied by license and configuration.
There is an additional complication for Office 2024 Home and Business for Mac. Microsoft documents that the toggle to revert to the legacy Outlook client is unavailable in that edition. An organization that buys or provisions that software cannot assume users will retain a simple escape hatch for an AppleScript-dependent workflow.
Keeping legacy Outlook in place also does not solve the governance problem. It can leave a company supporting two mail clients, two sets of support instructions, and a hidden group of users whose core processes are incompatible with the direction Microsoft has selected. It is a containment measure, not a compatibility commitment.
What Mac administrators should do now
The practical response is an inventory, not a blanket migration order. Microsoft’s cancellation applies to the new Outlook for Mac across the public and government cloud scopes listed in the roadmap item, so tenant type does not preserve the promised feature.
- Identify users who run Outlook-related AppleScripts, Automator actions, Shortcuts, Keyboard Maestro routines, or homegrown attachment and mail-processing tools.
- Test scripts against the current new Outlook for Mac rather than relying on the old December 2025 roadmap date or an assumption that a future Current Channel build will add compatibility.
- Document the trigger, Outlook data accessed, macOS applications touched, credentials used, local file operations, and expected result for every identified workflow.
- Separate workflows that can be rebuilt as a managed Outlook add-in or Microsoft Graph integration from those that require local Mac automation outside Outlook.
- Avoid retiring legacy Outlook for affected users until a replacement process has been tested with real mailboxes, real attachments, and the organization’s retention, sensitivity-label, and Conditional Access requirements.
- Tell business owners that Microsoft has cancelled the feature, rather than describing it as delayed. That distinction changes whether a team should wait, fund redevelopment, or select another client for a particular role.
Microsoft’s decision closes a long-running roadmap item, but it does not close the automation gap for customers that relied on it. The next action belongs to organizations: find the scripts before a client migration finds them first.