The SaveToMerus button in Word 2010 for Windows

Support for us is as much about responding to clients who contact us as it is about us reaching out to clients when we notice something that might be giving them trouble. Last week, MerusCase Support received some auto-generated notifications indicating failed SaveToMerus updates from a particular firm, so we began to investigate.

When you download or merge a .docx document in MerusCase, it shows up on your computer as a .docm "Word macro-enabled" file. These .docm files contain the programming for the SaveToMerus button and an ID or "token," which MerusCase uses to send SaveToMerus updates to the right document in the right case once you press that button. These tokens also serve to add extra security by making it very difficult for anyone to fraudulently upload documents to your firm: the tokens are unique, have to match what's on our server, and expire 1 week after the initial download or merge.

Once we pulled up this firm's failed updated documents in our orphaned uploads folder, we processed the tokens on their documents and discovered that the tokens in the document were expired, with original merge/download dates that were a few weeks old. We gave the client our recommendation: when doing running updates of documents, you should SaveToMerus frequently while editing and re-download the updated document before every big edit session, as this both keeps you inside the token expiration window and ensures you're always working with the most up-to-date version of the document.

We've had these sorts of expired token notifications before for users who save a document to their computer and start working with it weeks or even months later, and we thought we'd resolved the problem for this firm, as a user there confirmed with us that they were able to QuickSave from a fresh download. However, a short time afterwards (and within the token expiration window), we began seeing more of these notifications from the same firm.

Support, at this point, knew there was a problem with the particular documents involved that went beyond a simple expired token. With the firm's permission, we sat down with one of MerusCase's software engineers and took a look at one of the bad documents, running it through several plausible upload and SaveToMerus scenarios in our secure testing environment. 

Our engineers monitored the token in the document pre- and post-upload, and were eventually able to discover the culprit: if a document is uploaded to a case with the Manual Upload tool under Documents -> Upload Tool, and it already has a token, then that original token is preserved through any subsequent downloads. Thus, if you merge a document as a .docm and upload it manually to a case instead of doing a SaveToMerus, it'll have a token dated from the original merge the next time you download it from the case and even fresh downloads will eventually expire once 7 days have passed from the date of the original merge.

Armed with this new information, we advised the user that SaveToMerus is the preferred method for putting merged .docm documents back in to their cases. Uploads with existing tokens (.docm files) via the Upload Tool are very uncommon due to widespread SaveToMerus use when users work with .docm files, but we still opened a feature request to process tokens in manually-uploaded .docm files. Those types of document uploads may be rare, but we still want to handle them and give the user a good experience.