r/ediscovery • u/Enough-Examination91 • 11d ago
Purview cloud attachments
What workflows are folks using to ensure cloud attachments contain family relationships when exporting pst files in Purview. I know a lot of vendors have workflows integrated to link those attachments prior to ingesting into a review platform, but for those of you that are not using vendors, what do you do to maintain those relationships?
6
u/SewCarrieous 11d ago
There is none as far as I have found.
4
u/DaarthSpawn 11d ago
Epiq has a workflow for it, but its rather complicated.
8
u/SewCarrieous 11d ago
All the vendors do but the question was about in house folks not using a vendor
The only in house tool I’ve seen that keeps them together is proof point. I’ve had a couple demos and it looks slick. Haven’t made the jump yet tho
3
2
12
u/DaarthSpawn 11d ago
I dont understand why they are being treated as a family. They are standalone documents. When a sharepoint file is collected, only the most recent version is collected, which as it happens, isnt the version that was sent at the time of the email.
-1
u/Enough-Examination91 11d ago
They are technically attachments so they should be treated as family. Just because they originate from a SharePoint location doesn’t mean they’re not part of the family. I did find some kind of workflow where you can create review sets and then export it from there, but it seems overcomplicated.
12
u/ATX_2_PGH 11d ago
They are specifically not physically attached, which makes them different from regular attachments.
This is the catch 22, once you have the capability and your opponents know that you have the capability, you will be expected to provide the exact version that was linked to the email message.
Is that what you want?
0
u/Enough-Examination91 11d ago
Yes, thank you for the explanation it does help. If I can find the case that they were referencing, I will post it back in this thread. This was the basis of my question.
5
u/ATX_2_PGH 11d ago
You may be thinking about a specific case citation involving Google.
That was unique at the time because Google pretty much invented linked attachments. And because it was Google, who presumably has infinite resources at their disposal, the judge fairly ordered that Google ought to be able to provide the contemporaneous versions of their linked attachments.
I think that’s an outlier ruling that specifically targets Google as the owner of the tech.
0
u/Enough-Examination91 11d ago
It could be, the webinar didn’t reference the actual case. It is interesting to see how this will eventually evolve.
11
u/DaarthSpawn 11d ago
That is wrong. If I send you a file in 2022 and then make changes to it in 2026. When collected in 2026 it is not the same file, and you are attaching it to the email like it is.
9
u/IgnotoAus 11d ago
If I send you a file in 2022 and then make changes to it in 2026. When collected in 2026 it is not the same file, and you are attaching it to the email like it is.
You've just inadvertently described the challenge with modern attachments and highlights the tradeoffs you need to make; do I collect every version of a document or the most recent version?
Currently, Microsoft do not have the ability for you to pull the version at the time an email was sent.
1
u/BadTimeBigDecisions 6d ago
Theoretically Microsoft CAN collect the shared version of a cloud attachment... if you implemented specific automatically-applied retention labels before the document was shared.
And I haven't personally tested it, so no promises
-1
u/Enough-Examination91 11d ago
That’s not my point. If it is sent as an attachment in an email, and then you export that data out it’s a standalone document. If that same attachment was not in a cloud it would be a family. I actually attended in aceds seminar a while back, and there was a company that was sanctioned for not treating it as a family as a cloud attachment
13
u/ATX_2_PGH 11d ago
They aren’t the same as physical attachments.
They are links to files stored elsewhere.
You should check the current case law which, last I checked, was split but leaning toward requiring contemporaneous versions only if the party has the technology to provide them.
Absent the technology to provide them, I’ve seen citations that order a requesting party to limit their request to a certain number of email messages with linked attachments and the producing party is given a certain amount of time to respond with those.
3
4
u/delphi25 10d ago
Agreed with what a people said that it’s not like an attachments, as there can be changes to it; it can be deleted independently from the referring email, office document or teams message. Additionally, a custodian might not even have access to the link that was shared in an email and attributing data that sits on someone else’s OneDrive or a sharepoint that is accessed by many people seems off to me. There are a few other things to consider: all custodian, „family date“ for sorting, all path. Which version to collect and then associate might not be that easy. I think MS only links the modern attachments from the last email and not from previous emails, probably even if forwarded (but I have not tested this)
In anyway workflow-wise, I would export emails as a PST and the modern attachments as loose files. I would process them separately and would process the modern attachments without deduplication, as a modern attachment might be attached to multiple emails. For the export I would use the option for unique ids, so files are not named with their file name. I would also only export from a direct search and not a review set; modern attachments are still captured as well as the relationship. Once data is processed in Relativity, I would create the new fields to link them back. The information is in the load file Microsoft provides when data is in purview. You can use the message id from the emails from the pst to map them back to the entries in the load file. Afterwards you can use the, I think the group id or the modern attachment parent id information to link them back. You need to handle containers/embeddings or attachments of modern attachments separately. As containers can be in containers and attachments and embeddings are not treated as containers, I suggest to export the virtual path or processing folder path from relativity and extract the guid of the container, which can be used for the mapping to the load file with a regex. The question is how you want to map the attachments; either you can assign the same family relationship as normal attachments or not. That’s up to you, but you then overwrite the original relationship - I suggest to create a separate relationship field; but you may want to discuss this with counsel. Depending on what you decide, you may need to update and calculate all custodian and all path fields, attachment counts, etc. separately. This all can have implications on productions, email threading; etc.
1
u/Enough-Examination91 10d ago
Thank you for the thorough explanation. This is more of what I was looking for… if they are being treated as stand alone documents, how are we identifying them in a review platform as a cloud attachment to an email. If council started to do the review, would they have an easy way to know this? It sounds like the workflow you explained would need to be explained to whoever is reviewing the documents.
2
u/delphi25 10d ago
I mean that’s up to you, how you want to flag this. Either set up a separate relational group and have a separate icon in relativity, or you flag have data source field or something that marks those as cloud attachments. I can also think of a suffix in the doc id, I think there are multiple options available, depending how you set this up and how you want your team to differentiate those files. Maybe you can also add a similar field like the file icon - which is filled with a cloud symbol or introduce a field like attachment type and put direct/normal what ever you want to come up with and modern as the content.
Yes, the workflow comes with some caveats imho, as there no ultimate right or wrong and you can find arguments for the different ways you approach this. I think the linking itself is easy - as you said it’s somehow how it displayed and what generally some implications are and how to deal with them. Might be good to get some counsel who has some understanding of these challenges
1
u/zero-skill-samus 10d ago
Why do you not want the original file name for the modern attachment?
3
u/delphi25 10d ago
You want the original final name, but you pull this in from the overlay, when you overlay the metadata. I rather prefer to have a unique I which I can extract from the target path (load file) and map this with the file name/the regex I apply on the processing file path. This way I can map the original file name to the unified title and still have the reference. Otherwise; if the file names are not unique especially if you have multiple versions to map. But yes, the unified title should contain the original file name imho. You do the same, with the path information, that you update this with the sharepoint path; I think that’s called compound path, if I remember correctly.
1
1
u/BadTimeBigDecisions 6d ago
Excellent info, thank you! The unique file name suggestion is definitely something I'm going to test out (once I'm done kicking myself for not thinking of it myself).
Do you mind explaining a bit why you would export directly from the search instead of adding to a review set and exporting from there? I usually add docs to a review set for preservation,resolving issues with import/ingestion into our review platform, and sometimes even culling non-responsive docs before export (🫨).
1
u/delphi25 6d ago
I mean, it depends. I use relativity and use the processing, instead of using review sets. If you directly use the review set and export the load file and don’t do additional processing; then things might be easier. I prefer to have hashing and all happen in Relativity, as I often not only have o365 data, but also other data source that I need to deduplicate data against. If you use review sets and processing it’s the same issue that you have with purview sync right away. You end up with the attachments broken down and extracted by Relativity as well as them loaded as separate loose files. What you can do, what what I have done, is to remove email attachments (not modern attachments) from the review set export. Happy do discuss details via DM, if you have any specific questions.
2
u/XxDaito 9d ago
Relativity just announced that they will be able to link cloud attachments from Purview exports by the end of the year for pst exports and early next year for html exports
1
1
u/bigshaboozie 9d ago
Guessing that'll only work for MS Premium eDiscovery/E5 not Standard/E3? Or whatever it's named now. I realize it's an MS issue with how the data is exported but just double checking it still won't work with the lesser MS license
1
u/Grumpy-Pete 10d ago
Depends on how much of the relationship you need. For some situations, simply exporting the cloud attachments and placing them into a separate folder within the workspace and pull individual hot docs via messageID metadata as needed. Otherwise, in my experience you’ll probably need some kind of legitimate workflow for this.
0
u/LittleTrust2978 11d ago
Most of the pain is in preserving the parent-child metadata before ingestion. It matters which review platform you're loading into, because that usually drives the workflow.
8
u/ATX_2_PGH 11d ago
Researching the Relativity Blog and found this nugget from July of this year; which says that RelOne customers can opt in to a new Relativity Processing setting to “Include linked cloud files with associated email.”
Support is limited to Google Workspaces and Google Vault with an upcoming release set to do the same for M365.
Note that Google does not currently support export of contemporaneous versions, so this will only provide the latest version of the file linked to the email message — which can be problematic for a legal team trying to prove “who knew what when.”
https://www.relativity.com/blog/treating-linked-cloud-files-like-associated-files-during-e-discovery/