69b7f8704f00 I don't know if this helps you. I created an nginx rule to work-around the issue https://community.atlassian.com/t5/Confluence-questions/How-can-I-add-non-http-url-to-a-page-e-g-vscode-mailto/qaq-p/2939351#U2940814 

I'd like to use this to add  vscode links such as [vscode://settings/editor.wordSeparators] to make it easy for our developers to change the settings they need.

Seeing that a 18000 user company request this feature and it isn't solved ASAP gives me little hope. 

We also need that for my company (18000 users) for using with an internal tool that defines its own protocol.

We migrated thousands of pages with this from datacenter where is was working, and now people can't continue to edit their page the way they used to since 10 years.

This affects both new and legacy editor (which allows to add the link, but it <a href...> is lost when you publish the page.

https://getsupport.atlassian.com/browse/CES-62718

Dare i ask what's the progress on this if it was created in 2009?

We are in need of linking excel files and forcing them to open in the desktop app rather than the web view in SharePoint (using the "ms-excel" protocol. (e.g. "ms-excel:https://sharepoint.LinkToFile").

MS have done us all dirty and introduced "web view" for MS documents on SharePoint. Besides the fact it messes up word documents, our problem is, excel macros are inconsistent and we cannot reliably rely on the macros within in the web view.

However we still need to link the documents in our confluence documentation so staff know where to go / can access the files. I would rather not have to rely on peoples "good will" to not mess with the data in the sheets where the macros would normally prevent this (in desktop mode).

Now there's nothing stopping a user manually navigating to SharePoint and viewing it in web view there - but we could mitigate it to a degree if we could force the file to open in the excel protocol!

15 years in the making...

Adding the possibility to allow custom links would be highly appreciated. It would save our users manual work by supporting using Confluence together with organization internal applications.

It could be a setting where we define a list of allowed protocols. In our case, it would be "fmp://".

Thank you.

We seriously need this ability as well. We deep link into our desktop apps and users can open areas of the app and try different things just by clicking a URL in documentation when custom schemes are supported

It's not really a security risk once certain schemes are excluded (like javascript), as the browser already handles alerting the user about the action from the URL and the user can allow/refuse/etc.

Also, the ability to disable opening a link in another page would be valuable, otherwise our users would keep getting empty pages when linking out to our apps

Deep links are a big deal these days on mobile and desktop - please ensure documentation can use them!

Please add this!

Using an external service such as TinyUrl is interesting but is a security risk and restricts our control over our own data. Setting up a custom service that does the same kinda defeats the idea behind having our Confluence instance in the Cloud. We really would like this restriction to be removed, too.

@Paul Ev: same here. We've documented our deeplinks on Confluence, as well as our manual test procedures. Would be great to be able to use this.

We need to test our iOS apps with our custom app scheme. Would be nice to be able to do this from our Confluence pages.

I found a workaround!

Use TinyURL!

You're welcome!

For us, it's s3:// links. They broke the whole Confluence page, luckily I found a draft by backtabbing in browser...

I was just pointed to this ticket. 9 years? Really? 

Think you might be able to get on this one? For us it's "bjn://" links. 

This thing has been open since 2009. Atlassian, what are you doing???? Fix it already!

Yes, please add support for slack:// links

I will throw my support for this limitation to be lifted in Confluence. It works in the browser. It does not seem to be a costly improvement. 

In my case, I'm trying to link to Figma desktop documents.

Sadly yet another issue that Atlassian has ignored for ~10 years.

Like Jeff, I’m also trying to create “slack:// links for documentation. This request has been open for a VERY long time, please schedule for a fix.

I'm looking to leverage this capability to deep link to our teams various Slack channels from within Confluence. This allows Confluence to be our teams' "source of truth" for documentation as well as allow for deep linking into native apps to increase productivity by not having to navigate within other applications to find related information for our various projects.

I encountered the issue while writing documentation about deep linking in our app. I've gone into detail in this thread https://community.atlassian.com/t5/Confluence-questions/Adding-external-links-that-aren-t-URLs/qaq-p/459744 where also stated that all the suggested workarounds found thus far, seem to apply to Confluence Server only. In summary, I'd like to use custom links such as myapp://menu/section that persist after the page is edited.

I just encountered the problem while trying to link to our company's homebrew document management system.
It is using links with the scheme "edmdoc:", but such links are translated to <a rel="nofollow" target="_parent">MyDocument</a> by the RichText editor.
On the other hand a URI using "edmdoc://" is translated into a real link, but the document management system is complaining about the double slashes.

When I try making a shortcut with key "foo" and expanded value "foo://" it complains "Shortcut expanded value in not a valid URL in Confluence 5.4.3. So the work around does not seem to work for me.

True support for custom protocol handlers would be very useful here. It's weird to even say "support" since support is provided by the OS and the web browser. The fix needed here is for Confluence to stop blocking the support that's being provided by the other parties.

If there were security concerns just have "custom protocol handler" support off by default. Or have a whitelist of allowed protocols which we can set.

Suppose we have a desktop application called CityViewer. We have 10,000+ cities in the product. We want to clickable links on your Confluence pages. Maybe a page with the top 100 cities, one with cities in Europe or Cities from A to Z. The URL's would be like cityviewer://paris.

Seems like a very simple and reasonable thing to do? Would be very nice if it worked!

As a work-around, I found that I can create a shortcut link with the non-http protocol.

i.e.
Shortcut link is "protocol://%s", alias is "@protocol"

So, I paste in my "protocol://" link, delete the first part of it, then type "@protocol" at the very end and it becomes a link in a Confluence page.

I've gone into gory detail here: https://answers.atlassian.com/questions/31829

Any progress on supporting more protocols? I'd hope this would be an easy fix?