If you’ve clicked “Email Link” or “Email Copy” in NetDocuments and found yourself looking at an unfamiliar web form in your browser instead of a new Outlook message, something is misconfigured on your workstation. There are two likely causes, and this post walks through both.
What You’re Seeing
NetDocuments has two ways to handle Email Link and Email Copy: it can open a new message in Outlook or fall back to a built-in HTML email form in the browser. The Outlook behavior is the correct one — the browser form is a fallback that bypasses Outlook entirely, giving you none of your contacts, signatures, or familiar compose window.
When it’s working correctly, you never see the browser form. When you do, one of two things has gone wrong.
Cause 1: Desktop Email Integration Is Not Enabled
The Outlook behavior is controlled by a setting called Desktop Email Integration, which should be enabled on every NetDocuments workstation. It’s configured via a registry key:
Key: HKEY_CURRENT_USER\Software\NetVoyage\NetDocuments\useMapi Type: REG_SZ Value: True
If this key is missing or set to False On the affected machine, that’s your problem. The most common reasons it goes missing:
To quickly fix it for a single user, they can go to Settings > Application Settings in NetDocuments and check the box next to Desktop Email Integration.
Cause 2: Local Network Access Is Blocked in the Browser
The second cause stems from a browser change that caught many firms off guard. Chrome 142 and Edge 143 introduced a requirement to explicitly enable Local Network Access — in previous versions, it was on by default. This change broke ndClick’s ability to bind to the local port it needs to operate, and one symptom is that Email Link and Email Copy fall back to the browser web form instead of opening Outlook.
A tell-tale sign this is your issue: the user is also seeing documents download instead of open, or documents are showing a persistent green checkmark after editing (stuck checked out).
The fix is enabling Local Network Access in the browser. NetDocuments has published a guide for IT administrators to implement this firm-wide via policy: Configure Local Network Access permissions for NetDocuments
For a full walkthrough of check-in troubleshooting, see our guide: Troubleshooting NetDocuments Check-In Issues
Which Cause Is It?
A quick way to tell: if the user has no check-in problems and documents open normally, start with the registry key. If they’re also experiencing stuck checkouts or documents downloading instead of opening, the Local Network Access setting is almost certainly the root cause of both symptoms — fix that first.
Running into NetDocuments configuration issues at your firm? Schedule a free consultation or visit our contact page — we’re happy to help you get things working correctly.