Filesurf, which was rebranded CA Records Manager and goes by CARM, is an electronic records management system by CA, originally developed by MDY. According to the official product write-up:

It is a product that manages, controls and discovers physical, electronic and email records via a single policy engine to become the policy authority for enterprise information. It reduces end-user burden and administrative overhead while providing comprehensive life cycle management of your corporate knowledge assets across your enterprise content silos.

The laughable part of that description is that it reduces end-user burden. In my experience, it creates a huge amount of confusion, frustration and resentment in the end-users. I’ll get to that in a bit.

My firm uses Filesurf (we don’t call it CA Records Manager or CARM, yet) in large part to archive email messages which can then be deleted from the mail system. It creates copies of email messages, stores them in an archive, and provides a web-based method of locating these messages.

That sounds like a very useful thing to have, and your company may be tempted to use Filesurf to archive and later access its email. But Filesurf is a shockingly miserable, ugly and brutish piece of software to work with.

As someone who appreciates the difficulty of developing usable, intuitive web-based application interfaces, I feel totally justified in saying this thing’s front-end is a jaw-droppingly awful bit of programming. The laziness of the interface engineers permeates every page and error message.

The search functions are primitive, frustrating, and time-consuming. Locating specific emails is very much like finding a needle in a haystack. Glaring limitations of the web-based interface prevent effective narrowing of search results.

For example, it’s possible to narrow a search by sender, and it’s possible to run a full-text search on the body of the email, but you can’t do both at the same time. They’re actually on two different web pages. You can’t even do one and then apply the other to the results as a filter. Why on earth can’t CA combine these two search functions? Any web programmer who has ever worked with a database could do this in a matter of minutes. I’ve personally written much more complicated database search queries in PHP.

The results appear as a list ordered by date sent and are not sortable.

Searching Filesurf: A case study

Today I was tasked with helping a user locate an email attachment. The user knew who sent the email, what the attachment was named, and where the email had been located in the mail system before being archived. The user also had some idea about when the email was sent. That’s a lot to go on. Unfortunately, Filesurf is so poorly designed that much of that information can’t be used as search criteria.

To begin with, it isn’t obvious that Filesurf can handle date ranges – there is only a single input field for date. You can’t search for attachment file names, or limit results by attachment type, or even just by whether an email has an attachment. If users typically forward emails ‘as attachment’, they can’t be differentiated from Word, PDF, or image file attachments.

So what usable criteria are we left with? Just the sender and the folder from which the email was archived, or the “source path”. In this case, sender doesn’t further limit the results from the source path search. So while the user has four different bits of information about the archived item, only two of them are usable, but from the interface, it appears only one of them is usable.

After performing the search, I was left looking at a list of hundreds of emails, maybe a third to half of which have attachments. I can view the details of each email, but attachments do not show up in the details screen. To view the attachment names, I have to open each email and look at the attachments.

If you are considering CA MDY FileSurf, I strongly recommend having someone on your staff who can devote many long hours to nothing but wrestling with the horrendous search function – sifting through hundreds of irrelevant results that should never have been returned in the first place.