Why New Outlook is not yet ready for metadata risk management in legal
Oct 8, 2026
What legal IT teams need to know about modern Outlook integrations.
Metadata cleaning is, in many ways, the sister tool to document comparison. Both are risk management tools and they were bundled together at Workshare in the early 2000s. Comparison manages risk by helping lawyers find changes in a document. Metadata cleaning manages risk by helping prevent sensitive information from leaving the firm.
For most lawyers, metadata cleaning is not something to spend time thinking about. It should happen out of sight and out of mind; quietly while they draft an email. In practice, software integrated with Microsoft Outlook identifies attachments, applies the firm’s cleaning policy and replaces the original files before the email is sent. This email integration allows IT administrators to enforce metadata cleaning when documents leave the firm, rather than relying on every user to proactively remember to do it manually.
That is why Microsoft’s transition from Classic Outlook to New Outlook presents a challenge for the legal industry. New Outlook requires vendors to replace traditional COM add-ins with modern Office.js add-ins. Firms want those modern integrations, but many also want sensitive document processing to remain on the user’s device. Building a solution with that combination is possible. But the harder problem is confidently determining what has happened to an attachment inside Outlook.
After more than a decade building document software that integrates with Microsoft Office, we have found that New Outlook does not yet provide a sufficiently reliable foundation for firms that depend on attachment-level controls in email with a local desktop cleaning application.
And the issues that sit behind that finding aren’t just an issue for Draftable products. They will likely impact any Outlook integration that modifies, replaces or verifies email attachments.
Why modern Outlook add-ins are different
Earlier metadata cleaning products were generally built using Microsoft’s COM add-in technology. Both Outlook and the metadata cleaning software ran on the user’s computer, giving the software direct access to the local Outlook application.
New Outlook uses a web-based architecture and does not support traditional COM add-ins. Vendors must instead build modern add-ins using Microsoft’s Office.js APIs. This does not mean documents must be uploaded to the vendor’s cloud. Draftable Clean, for example, uses a modern Outlook add-in while cleaning document contents in a desktop application on the user’s device. But as with New Outlook itself, the Office.js APIs are a different technology for building integrations. And they are remarkably difficult when trying to reliably replace an original attachment with a modified (e.g. cleaned) version and confirming that the correct file will be sent.
What we found when working with Outlook attachments
Draftable Clean works by identifying attachments that require cleaning, sending their contents to the local desktop application and then using Office.js to replace the original attachments with cleaned files.
That sounds straightforward, but in practice it’s more complicated than it appears. To begin with, Outlook maintains a local draft and a server copy that synchronises with Exchange on its own schedule. This means the attachment information presented by Outlook can be separate from the underlying file contents. For a modern Outlook add-in, this means it’s possible to receive conflicting or incomplete information about the state of an attachment being tracked. To help explain this further we’ve outlined specific issues our team identified when building our Draftable Clean add-in.
- A completed Outlook operation is not always complete. When an add-in asks Outlook to remove an attachment, Outlook sometimes reports that the request has succeeded before the change is reflected everywhere. The reverse can also happen. Outlook sometimes stops waiting for an operation and reports a timeout, even though the operation is ongoing and can even be completed later on. During development, we observed removal operations completing well after the add-in had stopped receiving a response from Outlook.
For software like ours that is designed to manage risks by enforcing metadata policy, this creates a serious problem. A successful response confirming an operation is no longer enough to prove that an original attachment (with metadata) is gone, while a timeout does not prove that it remains. - The attachment list and the attachment contents can disagree. To get around that unreliability, you can look at other data about the attachments. Outlook exposes an attachment record containing information such as the file name, size and ID. The underlying file contents are retrieved separately.
During internal testing, we observed situations where email attachment lists provided by New Outlook temporarily omitted files in the email. In other cases, a listed attachment could not yet be read for additional data, and where an attachment record appeared to represent a cleaned file (e.g. based on file size changes) the underlying content in some instances still contained the original size.
In other words, an add-in cannot safely rely on the visible attachment list or a single status response. It instead needs to verify the attachment content and account for any temporary disagreements between the local draft and the server copy. - Attachment IDs can change while a draft is open. Another complication is how attachments themselves are identified. An attachment ID recorded at the start of a cleaning process may change after Outlook saves or synchronises the draft email. This is particularly significant in New Outlook, where attachment IDs can “rotate” whenever a draft is saved. The result is that add-ins cannot safely treat an attachment ID as a permanent unique identity for a given file. The workaround to ensure reliable file matching requires additional information such as the file name, size and content hash. Even then, there are ambiguous cases where the email processing must stop rather than create the risk of deleting the wrong file copy.
- Outlook’s timing limits conflict with reliable verification. Another way to improve reliability is to slow the file replacement process down, and allow Outlook time to synchronise and verify each step before continuing. But Outlook also imposes strict time limits on add-in operations. In Outlook on the web, for example, we found processes that were reported as abandoned after a minute, but then were subsequently completed another minute later.
All of these issues create a tension between speed and reliability. Moving too quickly can cause operations to overlap with Outlook’s own file saving process. Waiting and retrying can exceed the time available. If the add-in cannot determine the true state of an email attachment list, the safest option is often to keep both copies rather than risk losing an attachment, or interrupt the send rather than sending the wrong one. In all cases, the user experience suffers.
Classic Outlook is more reliable, but not perfect
These problems are most acute in New Outlook and Outlook on the web, but Classic Outlook is not immune.
During development we also encountered incomplete reads, attachment records that temporarily disagreed with their contents and operations that Outlook reported as successful before their effects could be verified.
The difference is that with the safeguards we have developed, the current Draftable Clean build has performed reliably in our testing of Classic Outlook. In one recent test sweep, the build completed 39 out of 39 scenarios successfully across emails containing between one and 13 attachments. One send-time verification warning was resolved through review and retry.
While these examples are from one particular build and a single test protocol only, they are indicative of a much larger process of quality assurance that has given us substantially more confidence in Classic Outlook than in New Outlook today.
What this means for legal IT teams
Microsoft has described a three-stage transition from Classic Outlook to New Outlook: opt-in, opt-out and eventual cutover. Microsoft says existing installations of Classic Outlook will be supported until at least 2029, but it has not announced the final cutover date.
Law firms should use that transition period between Classic and New Outlook to stress test modern add ins. If your firm depends on metadata cleaning, document filing or another attachment-level control system, it’s not safe to assume modern integrations provide the same level of enforcement in Classic and New Outlook. Ask vendors:
- Where are document contents processed (locally or via the web)?
- How does the product verify that an attachment was actually processed properly?
- Does it verify contents or only check the file name, size or status returned by Outlook?
- What happens when Outlook times out or returns an incomplete attachment list?
- Can the product prevent sending if its verification cannot reach a conclusion?
- What limitations apply specifically to Classic Outlook, New Outlook and Outlook on the web?
We recommend that firms test their complete email risk controls in New Outlook before allowing a broad rollout. Testing should include working with a larger number of attachments, large files, mid draft recipient changes, interrupted network connections and attempts to send while attachments are still being processed.
For organisations whose work requires enforced metadata cleaning, our current recommendation is to rely on Classic Outlook until the firm has verified that its required controls operate reliably in New Outlook.
What we are doing with Draftable Clean
Draftable Clean combines a desktop cleaning application with a modern Outlook add-in. The document contents remain on the user’s device while the add-in manages attachments within Outlook.
To work around the behaviour we have documented in this article, the add-in does not treat an Outlook report of success as proof. It runs a series of processes that independently verifies that the cleaning has taken place properly. On New Outlook and Outlook on the web, it also performs additional checks against the saved server draft before sending.
These safeguards reduce risk, but they come at a speed performance cost. And depending on the firm’s configured policy, where processing cannot be verified, Outlook may block the send or ask the user to review the message.
Ultimately, our testing demonstrated a difference between the Outlook clients, and that is why we are treating New Outlook and Outlook on the web differently from Classic Outlook.
Draftable Clean for New Outlook and Outlook on the web will therefore be offered as a beta at this stage. We believe it is useful for firms that otherwise have no metadata protection on those platforms, and we are confident in its ability to stop emails from being sent with uncleaned attachments. But firms should understand the user experience limitations of those blocks and decide whether the beta is appropriate for their users. Where it isn’t suitable, administrators and users can be given the option to disable Cleaning in New Outlook and Outlook on the web.
As we evolve Draftable Clean, we will continue sharing our findings with Microsoft and testing improvements to the Office.js APIs. We expect New Outlook will mature as it becomes more widely adopted, and will reach suitable reliability ahead of any decision by Microsoft to end support for Classic Outlook.
