- OS: Windows
- Browser: N/A
- Office: 2010, 2013, 2016
- Products: EMS, ndOffice
When filing email messages into NetDocuments, email messages are de-duplicated, meaning if a copy of the same message already exists in NetDocuments, subsequent copies will not be imported.
How De-Duplication Works
There is a slight difference between EMS Folders and EMS Profiler with regard to how the already-imported message is handled when an item is de-duplicated:
In most cases, a firm’s cabinet will be set up to default the Document Type (organizing attribute) and Author values. For example, all messages imported via EMS will receive “Email” as the Document Type and “Email” as the Author. Messages will be filed at the Matter/Workspace level and so they will all end up in the same container/filter on the workspace.
However, with EMS Folders, users have the option to drill down to a specific filter or folder on a workspace when importing messages. In this case, supposing UserA filed the message to the default value of Email, if UserB filed the same message to a filter called Correspondence, you could end up with the same message existing twice in the same workspace, each with different Document Types. To avoid this scenario, the system will not import the second message, but instead re-profile the already-imported message to Correspondence.
Messages filed via EMS Profiler will not result in the re-profiling of the already-imported matches. The duplicate message is not imported, and the existing message’s profiles are not changed.
This is because messages imported via EMS Folders are inheriting their attributes from the new container they are filed in. EMS Profiler doesn’t “file” to a container so there is no inheriting of a new attribute value.
ndOffice works in a similar fashion as EMS Folders, because a user can either 1) select a workspace as the destination and then profile it to a filter or 2) specify a filter as a filing location. This results in a similar scenario as with EMS Folders. For this reason, messages filed via ndOffice will also be de-duplicated and the already-imported match will be re-profiled to the new messages’ profile values.
NOTE: If the second user does not have E rights to change the profile of the already-imported message, then they will get an "access denied" message when attempting to import the new message because the user is unable to change the profile of the already-imported message.
ndOffice uses the REST API to send a search request to find identical messages. If the search shows the messages are in the same workspace, then we do not import the new message. If the user changes any non-workspace attribute of the new message (Document Type, Author, etc.), then the existing message is re-profiled to those new profile attributes.
When that attribute is a workspace organizing attribute (Document Type/filter) then the message gets moved from one filter to another, as if the user had re-profiled it.
If the user changes some other, non-organizing attribute, it simple gets that new attribute value.
In the end, when it is determined that the message was already imported, all that happens is ndOffice re-profiles the existing message. If the users file to any other location other than that workspace, then the message is imported since that message is in a different workspace.
For example, if a message is sent to two users, User A can file it in ABC Account / Some Matter with a workspace organizing Document Type set to “One Type.”
If User B tries to file it in ABC Account / Some Matter / “One type” then the message is not imported and the profiles are not changed.
If User B instead tried to file it in ABC Account / Some Matter / “Two type” then the already-imported copy of the message will be moved from filter “One type” to “Two type” but there is still only one copy of the message.
If User B changes any other non-organizing attribute (Author, etc.) nothing will be moved to another filter, but any new profile values will replace the old ones.
De-Duplication Flow Chart