Word and PDF hyperlinks tame Clio
I never liked database apps. And Software as a Service doesn’t thrill me much either. I just don’t want to hunt around someone else’s interface in order to get to my data. No matter how pretty the interface is. Sorry to be obnoxious. I want information at my fingertips when I want it.
But you can tame these beasts. At least, you can tame Clio.
When I write a client letter, or when I’m doing anything on a case, I want to get to my data for that matter with one click. That’s not one click in a browser window, where I have to open the browser or find it under all my windows. I don’t want the distraction. Just one click, and I want my data.
Turns out it’s easy. And also that there are some devilish details that make it not quite so easy.
Here’s the “use case.” I want “Our Ref” in a letter to a client to be a hyperlink to the matter I’m dealing with. If I open up the letter in Word (or as a PDF), I want to click that reference link and immediately get the Clio matter on my screen.
Clio has a fixed URL for every matter and client. If you look at the location field in your browser when you are “in” a matter, there is a “matter number” – and it’s a large number. Whatever that number is, no other case in the Clio universe has that number. It’s unique. Like your email address or your domain name.
So in theory it’s easy and not worth a blog post. Put that matter URL in a hyperlink in your Word document and it is just a click away. Wrap this trick up in your Clio letter document template, and every letter you write will link back to the matter in your practice management system. It is game changing. The app becomes 100 times more useful.
But.
First “but” is that Clio hasn’t yet read this blog post. So, as you construct your document template (not a word template, but a word document that has magic slots which Clio pre-fills with matter information – the Client’s name and address etc) you won’t find this unique identifier in the list of stuff it will put in your document for you. Easy to fix – but mildy irritating – you create a custom field for “clio ref” and then cut and paste the unique number from the URL field. And hopefully Clio won’t decide to make the URL prettier and hide that number. Then you can put the “link” in your document before you write it, and every time you access the document, you can click the link and Clio will bring up your data.
No.
There’s another “but.” You can’t put the Clio template markers in a Word hyperlink. That’s probably Microsoft’s “fault” – Clio uses << and >> to identify your <<clioref>> field – and if you put that in a hyperlink, Word will mess with it. These aren’t characters that you can usually put in a URL, and Microsoft will assume you weren’t trying to be clever. There may be more to the problem than this – I’m just making an educated guess.
So you don’t make a pre-prepared link. You have
Our Ref: http://app.goclio.com/matters/<<Matter.CustomField.Clioref>>
in plain text in your letter. Clio fills out the <<whatever>> magic when it expands the template for you, and the first thing you must remember to do when you start editing the document is select the URL and turn it into a hyperlink yourself.
Now you’re all set. You can click the link in Word and get to your document?
No.
Another “but.” You can cut/paste the link into a browser and it will work. You can create a PDF of the document from the Word file and click the link there, and it works (but there’s a wrinkle there too – come to that in a moment). And you can also load the document into other word processors that will read word format (Pages, OpenOffice, LibreOffice etc) and they all seem to work fine. Click the link when you need, and Clio gives you the matter data in your browser.
But not in Word.
Here’s why (and yes there is a workaround). Most applications, when they are given a hyperlink, read the hyperlink – and then they say “oh, it’s a hyperlink – let’s use a browser and open it” – and they use your browser and open the hyperlink. If you have logged into Clio on that browser, Clio knows you are already “in” – there’s probably a cookie doing that job – and the practice management system displays your data.
But Microsoft has always had to do more. It’s in their genes. You have to take a DNA test before you get a job offer at Redmond, and they specifically test with markers for the “need to improve it” gene.
Word is compelled to connect to the URL itself first, before delegating the task to the browser.
Bad idea.
Word says: “hello Clio – here is the URL my user wants to access”
Clio says: “aha – we don’t know about Word. There are no Word cookies. There are no users who have logged in to Word. So, that matter URL is wrong. What you need is the signin page.” And Clio gives Word a new URL to use. So you can log in.
And that’s what Word sends to the browser. Insane? That’s why Apple and Google stock are so highly priced these days. It’s a mindset. Microsoft can’t help themselves.
[aside to any SaaS provides who may be reading this – and since this blog has a PageRank of zero, that’s a vanishingly small number. If you need to offer a login page when someone tries to access content without your cookie in their system, you can embed the login content in the page you deliver. If you redirect the user to another page, your service will not integrate easily into your users’ workflow.]
My workaround? A small PHP script on my web site. You are welcome to use it – you can even use it directly to see it works
https://law191.org/m/<<Matter.CustomField.Clioref>>
If you use this URL instead of the direct Clio URL, everything works like a charm.
But I expect you don’t want to embed links to my practice web site into your Word documents. And maybe I don’t want that either. So here is the PHP script that does the magic:
<?php$browser = $_SERVER['HTTP_USER_AGENT']; if(strpos($browser, 'Word') != false) { Print('hello Word'); } else if(strpos($browser, 'ms-office') != false) { Print('hello Office'); } else { header( 'Location: https://app.goclio.com/matters/' . $_GET['value'] ) ; } ?>
You may not know PHP, but you can see what it does. If the “browser” says “hello, I am Word (on the mac) or hello I am Office (on a PC)” the script isn’t fazed. Otherwise (for the sane world) the script redirects you to app.goclio.com so you can go look at your matter data.
If you want to host that script on your own site or intranet, you could call it matter.php and put the following in your Clio word document template:
Our Ref:.http://mysite.com/matter.php?value=<<Matter.CustomField.Clioref>>
So now, everything is fine. We’re happy. Clio is happy and Microsoft is happy.
No
There is one more wrinkle.
For some reason, if (like me) you create a “ready for sending” PDF from a letter – so you can keep track of the fact you actually sent it, you may look at the letter in Acrobat Reader rather than Word. And may want to click the hyperlink Our Ref field.
And Microsoft catches you there too. When you generate a PDF from Word 2011 for Mac, you lose your hyperlinks. I suspect that the “quality control” gene is recessive and paired with the dominant “need to improve it”
PDF generation works fine on Word 2010 and 2013 for Windows. So one workaround is to sell your shiny new mac. Another is to take the Word document and print it using Pages or another product. See, it’s not a MacOS bug. Other word processors are quite capable of generating PDFs properly on a Mac.
As I said. It’s all easy. And Software as a Service means you can cut your IT budget. Right. But, once you start using the direct URL hyperlink to your data from your other applications, SaaS makes so much more sense.
Leave a Reply