Draftable does not launch from iManage, SharePoint or File Explorer

What to check when selecting a Draftable compare action outside the application does nothing at all, with no error message and no entry in the logs, and how to restore the missing URL scheme registration.

If choosing a Draftable compare action outside the application does nothing at all, this article will help you identify the cause. The typical report is that a user selects Compare with Draftable in iManage, SharePoint Online or NetDocuments, or right-clicks a file in File Explorer, and nothing happens: Draftable never opens, no error appears, and nothing is written to the Draftable logs.

The usual cause is that the draftable:// URL scheme is not registered on that machine. Every comparison started from outside the Draftable window is a draftable:// request, so if Windows has no application associated with it, the request is discarded before Draftable is ever involved.

First, confirm which problem you have

Several different problems are described as “compare does nothing”. Use this table to identify yours before making any changes, because the fixes are unrelated.

What you see	What it means	Where to go
Nothing at all happens. No error, no prompt, no Draftable window	The URL scheme is very likely not registered	Continue with this article
Your browser asks permission to open Draftable each time, and comparisons work once you allow it	Normal browser behaviour, which can be suppressed centrally	Allowing Draftable to launch from your browser and the iManage Work Panel
Draftable opens, but reports that it could not find or load the documents	Draftable started correctly but has no authenticated connection to your DMS	Check your DMS configuration, starting with Setting up your DMS to Draftable Legal
Comparisons work only while Draftable Legal is already open	The HTTP Listener Service is missing or not running	Alternative iManage HTTP listener service installation guide
A comparison starts and then fails with an error message	A comparison problem rather than a launch problem	How to fix unable to compare errors

The application itself will look completely healthy. Draftable Legal opens and compares documents normally when started from its own window, the HTTP Listener Service runs, the Office add-ins load and licensing is active. Only comparisons started from outside the application fail, which is what makes this misleading to diagnose.

Why the registration can be missing

Both installers register the draftable:// scheme while installing Draftable Legal. Two things combine to let a machine end up without it:

• A failed registration does not fail the installation. If Draftable is prevented from writing to HKEY_LOCAL_MACHINE\Software\Classes during installation, the installation still completes and reports success. Nothing surfaces at install time, so the problem is usually discovered much later by a user who cannot start a comparison.
• Machine-wide installations do not repair themselves. The per-user installer re-registers the scheme every time Draftable Legal starts, so a per-user installation recovers on its own at the next launch. A machine-wide MSI installation does not, so once the registration is missing it remains missing until an administrator restores it.

What prevents the write in the first place is usually one of the following:

• Endpoint protection or an application control policy such as AppLocker or Windows Defender Application Control blocking changes under Software\Classes.
• A Default Associations Group Policy that reasserts file and protocol associations and removes the entry afterwards.
• The account performing the installation not having rights to write to the registry. On a single machine this is also covered in Issue with registering custom Windows context menu action.

Because the cause is environmental rather than a fault in a particular version, updating Draftable Legal on its own will not resolve it.

Every comparison started from outside the Draftable window is a draftable:// request. When a user chooses Compare with Draftable in iManage, SharePoint Online or NetDocuments, uses the Office add-ins, or right-clicks a file in File Explorer, that action asks Windows to open a draftable:// link, and Windows passes it to Draftable Legal.

Windows can only do that if the draftable:// URL scheme is registered on the machine.

The installer registers the scheme, but a failure to do so does not fail the installation. Both installers register the scheme as part of installing, including in a silent or scripted installation. If that registration is prevented — most often because something in the environment blocks writing to HKEY_LOCAL_MACHINE\Software\Classes — the installation still completes and reports success.

The result is an installation that appears entirely healthy. The application runs, the HTTP Listener Service starts, the Office add-ins load and licensing activates, but no user can start a comparison from iManage, SharePoint Online, NetDocuments, the Office add-ins or File Explorer. Those actions do nothing at all: no error, no prompt, and no entry in the Draftable logs, because Windows has no application associated with draftable:// and discards the request before Draftable is involved.

Machine-wide installations do not repair this by themselves. The per-user installer re-registers the scheme each time Draftable Legal starts, so a per-user installation recovers on its own at the next launch. A machine-wide MSI installation does not re-register at startup, so once the registration is missing it stays missing until an administrator restores it. This is why the problem is normally seen across a managed deployment rather than on a single machine.

Checking whether the scheme is registered

1. Test the scheme directly

   Press Windows + R, enter the following, and select OK:

   draftable://?source=outlook
   

   The Draftable New Comparison window should open. If Windows reports that no application is associated with the link, or nothing happens at all, the scheme is not registered.

2. Check the registry

   Confirm that HKEY_CLASSES_ROOT\draftable\shell\open\command exists, and that the path it contains points to a DraftableDesktop.exe that is actually present on disk. A path left behind by a previous installation is as broken as no path at all.

3. Run the built-in system check

   In Draftable Legal, open Settings, then Help & Troubleshooting, then Diagnostics, and select Run system check. On versions before 26.6 this is Settings > Troubleshooting > System Verification.

   The check is named Microsoft Windows: Custom URL scheme supported. If it fails, the scheme is not registered as Draftable expects it. Note that this check does not distinguish between a machine-wide and a per-user registration, so use the registry check above to see which is present.

Restoring the registration

1. First, repair the installation

   Because the installer performs the registration, repairing the installation runs it again. For the machine-wide MSI, re-run the MSI over the existing installation with administrator rights, or use Repair from Programs and Features. This is the quickest fix for one machine, and it is worth trying before making registry changes by hand.

2. If repairing does not restore it, the write is being blocked

   Endpoint protection, an application control policy such as AppLocker or Windows Defender Application Control, or a Default Associations policy can prevent or later remove the registration. Add the Draftable installation folder to your endpoint protection exclusions, and permit the draftable URL scheme in any application control policy, then repair again.

3. For a managed fleet, create the values from your deployment

   Creating the values directly does not depend on the installer action succeeding, so it is the dependable option when you are deploying to many machines or when the cause has not yet been identified. The values are below.

Registry values

These are the values the installer creates. Use HKEY_LOCAL_MACHINE so the scheme applies to every user of the machine, and replace the executable path if you installed to a custom location.

Key	Value name	Type	Data
HKLM\Software\Classes\draftable	(Default)	REG_SZ	URL:Draftable Protocol
HKLM\Software\Classes\draftable	URL Protocol	REG_SZ	(empty)
HKLM\Software\Classes\draftable\shell\open\command	(Default)	REG_SZ	"<path>\DraftableDesktop.exe" "%1"
HKLM\Software\Classes\draftable\DefaultIcon	(Default)	REG_SZ	<path>\DraftableDesktop.exe
HKLM\Software\Classes\draftable\Application	ApplicationName	REG_SZ	Draftable
HKLM\Software\Classes\draftable\Application	ApplicationCompany	REG_SZ	Draftable
HKLM\Software\Classes\draftable\Application	ApplicationDescription	REG_SZ	Compare documents
HKLM\Software\Classes\draftable\Application	ApplicationIcon	REG_SZ	<path>\DraftableDesktop.exe

The URL Protocol value and the shell\open\command key are the two that Windows needs in order to open Draftable Legal. The remaining values are part of the registration Draftable Legal creates for itself.

Create all of the values, including the Application ones. Draftable Legal’s own system check expects the complete registration. If you create only URL Protocol and shell\open\command, comparisons will launch correctly but the Custom URL scheme supported check will still report a failure, which is misleading for anyone troubleshooting the machine later.

The default executable path for the machine-wide MSI is:

C:\Program Files (x86)\Draftable\Draftable Desktop\DraftableDesktop.exe

Creating the values from a script

Run this with administrator or SYSTEM rights after the installer has finished. The commands use reg.exe so they behave identically in PowerShell, in a command prompt, and inside a deployment tool’s script step.

$exe = "C:\Program Files (x86)\Draftable\Draftable Desktop\DraftableDesktop.exe"

reg add "HKLM\Software\Classes\draftable" /ve /t REG_SZ /d "URL:Draftable Protocol" /f
reg add "HKLM\Software\Classes\draftable" /v "URL Protocol" /t REG_SZ /d "" /f
reg add "HKLM\Software\Classes\draftable\shell\open\command" /ve /t REG_SZ /d "\"$exe\" \"%1\"" /f
reg add "HKLM\Software\Classes\draftable\DefaultIcon" /ve /t REG_SZ /d "$exe" /f

reg add "HKLM\Software\Classes\draftable\Application" /v "ApplicationName" /t REG_SZ /d "Draftable" /f
reg add "HKLM\Software\Classes\draftable\Application" /v "ApplicationCompany" /t REG_SZ /d "Draftable" /f
reg add "HKLM\Software\Classes\draftable\Application" /v "ApplicationDescription" /t REG_SZ /d "Compare documents" /f
reg add "HKLM\Software\Classes\draftable\Application" /v "ApplicationIcon" /t REG_SZ /d "$exe" /f

Writing this into a batch file instead? In a .bat or .cmd file the %1 placeholder must be written as %%1, otherwise the command interpreter replaces it with the script’s own first argument. The placeholder is what passes the comparison request through to Draftable, so it must reach the registry exactly as %1.

The scheme is active as soon as the values exist. Neither a restart of Draftable Legal nor a sign-out is required.

Confirm the executable path before you deploy at scale. Every command above depends on it. If you installed to a custom location with INSTALLDIR, use that path instead. On a machine that already has Draftable Legal running, Get-Process DraftableDesktop | Select-Object Path returns the path in use.

Per-user installations need per-user values. The values above are correct for the machine-wide MSI, which installs to Program Files. If the executable is under %LocalAppData%\DraftableDesktop\current\, it was installed with the per-user installer, and a machine-wide value pointing there will not work for anyone else on the device. In that case simply restarting Draftable Legal restores the registration, because the per-user installer re-registers the scheme at every launch.

A leftover per-user registration takes priority. Values under HKEY_CURRENT_USER\Software\Classes\draftable, typically left behind by an earlier per-user installation, override the machine-wide values. Draftable removes a redundant per-user registration automatically only when it points to the same executable as the machine-wide one. If it points somewhere else, delete the HKCU key so the machine-wide registration is used.

If the registration will not stay

If you restore the values and they later disappear, something in your environment is removing them. The usual causes are a Default Associations Group Policy that reasserts protocol associations, or an application control policy that blocks changes under Software\Classes.

To confirm, create the values, run gpupdate /force, sign out and back in, then check whether the draftable key still exists. If it has gone, the policy that removed it needs to be adjusted to permit the draftable scheme.

Deploying the fix across many machines

Applying the values by hand fixes one machine. If the registration is missing across a deployment, build the values into your deployment so every machine receives them, and add a detection rule so you can see which machines are affected. Both are covered in Deploying Draftable Legal with Microsoft Configuration Manager (SCCM), and the same approach applies to Microsoft Intune and to scripted silent installations.

Confirming the fix

Once the scheme is registered, start a comparison from your DMS. If it opens in Draftable Legal, the handoff is working end to end.

The File Explorer right-click entries are registered at the same time as the URL scheme, so if they are also missing, repairing the installation restores both. The values for creating them from a deployment are in the Configuration Manager deployment article.

If comparisons still fail after the scheme is confirmed as registered, collect your logs and contact [e-mail]. See How to retrieve error logs from Draftable Legal.