The available version associated with the communication in which the file was shared.
Gain control over cloud attachments
A preserved email says see the attached forecast. The link still resolves, but it opens a file that was rewritten six months after the message was sent. Cloud collaboration separated communications from the files they reference.
A cloud attachment is a relationship, not a file
A traditional email attachment is static. A cloud attachment is a link to a file held in OneDrive, SharePoint, or another repository, and from that moment the communication and the file exist separately.
The message records the link, sender, recipients, and time, but not the linked file.
The file remains in its repository and may change after the message is sent.
The repository identifies where the file is stored and who owns the location.
The relevant version may be associated with sharing, recorded access, or another event, not simply the current file.
Preserving the message may not preserve the file
A communication that says see the attached forecast is close to meaningless without the forecast, and the connection between the two is the part that disappears first.
An employee receives an email linking to a file in a colleague's OneDrive and is then placed on legal hold. The email is preserved in their mailbox. The file is not, because it lives somewhere the hold does not reach.
If the colleague and the repository fall outside preservation scope, the file can change, moved, replaced, or deleted. The message survives with a link that no longer resolves to what it did when it was sent.
CaseFusion closes the gap through a collect-to-preserve workflow: identify the communication, detect the cloud attachment, resolve the file and its repository, retrieve the selected versions, and preserve it all together.
Collect the current version only
A cloud-hosted file can change many times between the day it is shared and the day it is collected. Collecting the current version only reduces volume, and produces a file that may bear little resemblance to what was shared.
- Timing | May not reflect what existed when the link was sent, what a recipient could open at the time, or what changed before a decision was made
- Direction | Leaves the communication pointing at something that came later
or every available version
Collecting every available version avoids the context risk, and generates duplicative content at scale.
- Cost | Adds processing, hosting, analytics, review, and outside-counsel cost across versions that carry nothing new
- Findability | Makes the versions that actually matter harder to find among the ones that do not
Connect versions to events that matter
CaseFusion uses the information surrounding a shared file to support the version decision. That changes the question from which versions exist to which versions are connected to the events at issue.
A file is shared at 9:00 in the morning, and Version 2 is what exists when the link goes out. A recipient opens it at 11:30 and the file has not changed, so Version 2 is still the version associated with that access.
The author edits the file that afternoon. A second recipient opens it the next morning, by which point Version 3 is available, so Version 3 is the version associated with that second access.
The file changes several more times over the following weeks, and the current version is Version 7. Depending on the matter, the legal team may conclude that Versions 1, 4, 5, and 6 are not worth collecting.
Match the version policy to the matter
Different matters need different version strategies, and the technology should follow the strategy the legal team selects for each one.
The available versions associated with a recipient's first recorded access, their last during the relevant period, or both.
The versions associated with specific recipients whose interactions bear on the matter.
Selected versions associated with activity during a defined period.
The present state of the file, where it bears on the matter.
Additional versions associated with identified events, changes, or business milestones.
Record what was captured, and what was not
When CaseFusion collects a cloud attachment, it first attempts the version immediately preceding the moment the file was shared. Where that version is no longer available, CaseFusion records that it was not and captures the nearest available version instead.
- Retrieved | Which versions were retrieved
- Unavailable | Which were sought and could not be
- Substituted | What was taken in their place
- Automatic | Produced at collection time, without anyone requesting it
Works alongside Microsoft 365
Microsoft Purview provides native eDiscovery capabilities across Microsoft 365. CaseFusion connects cloud-attachment preservation and version selection to everything else the matter knows.
- Preservation and search across Microsoft 365
- Cloud attachment and file version workflows
- Review and export
- Results that depend on configuration, retention, and licensing
- The roles the sender, recipients, and file owner held at the tim
- Custodian scope and repository information
- Recipient-access events from indexed audit activity
- Matter-specific version policies and recorded decisions
Cloud attachments & file versions FAQs
What is a cloud attachment in eDiscovery?
Does preserving an email preserve the file it links to?
Should legal teams collect the current version or every version?
What is a shared version?
What does a recipient-access event establish?
What happens if the version from the time of sharing is no longer available?
Does CaseFusion replace Microsoft Purview cloud-attachment capabilities?
Can legal teams still collect all versions when a matter requires it?
Keep messages and their cloud attachments together
See how CaseFusion handles cloud attachments as part of the matter rather than as a separate retrieval problem.
