Anyone who has spoken to me for more than a few minutes <insert apology here> knows how strongly I feel about the “in-place” management of information. “In-place” means that content is managed in the same location that it was created and is not moved to another location or database for its long-term management. Primarily when we talk about this, we’re referring to content or information that users access as opposed to items that require very long term preservation or management and may sit in cheaper archival storage.
I have been known to liken “out-of-place” management to someone coming to my house and moving all the furniture I don’t use very often to a storage facility down the road. I can still go to the storage facility, but it’s not where I initially chose to put my furniture. I want to be able to find it right where I put it. I believe that users feel the same way about their information; they want to be able to access it in the location where they saved it, within their familiar structures.
But—of course there is always a “but”—I do have a couple of exceptions to this, and today I want to talk about emails.
Try as we might, email is a content source that we’ve never really been able to get complete control of. This may be because emails are stored separately from the rest of our traditional data (documents, spreadsheets, etc.). Emails are stored in Exchange and must be manually moved by the owner of the mailbox in order to be stored with other related information in a repository like SharePoint.
Consider this example: A contract that was created in a SharePoint library lives out its lifecycle there. However, the approval to move ahead with that contract was likely received via email. Therefore, the approval will sit in the Exchange mailbox, separate from the contract itself, unless the user moves that email to the SharePoint library (which rarely happens). If the users involved in the creation and approval of the contract leave the organization while these records are sitting in separate repositories, anyone else coming in who needs access to that information is not going to have a complete picture. They may have access to the contract itself, but unless they have access to the individual Exchange mailbox, they won’t have any visibility into the approval process.
That gets us to the crux of the issue: context. When is in-place records management not appropriate? The answer for me is quite clear—it’s not appropriate when we lose context. Context will always win over where the item is stored.
Just because context is important (vital, I would argue!) doesn’t mean it’s easy to maintain, especially when we’re asking the users to be primarily responsible for moving content to different locations. So what strategies can we use to maintain context across repositories?
- Make it really easy for users to get their information into the correct repository. You can do this by using Office integration tools that allow users to drag and drop emails to an Exchange folder that, in turn, syncs the folder contents to the correct location (Shameless plug: Check out AvePoint’s Office Connect). Essentially what you’re doing is embedding a technical action into a standard user process. As users are generally accustomed to saving things in folders, syncing the folder to the location where the content should be saved is something that can be done without their intervention. By using technology to enhance an existing business process, you’re giving users a better experience—and who wouldn’t want that?
- Clean up after the fact. With this strategy, you must knowingly accept that not all emails have been captured or managed and will require manual intervention from the information manager at a later date—either after the user has left the organisation or at a designated point in time. Alternatively, you can work with IT to get access to the user’s mailbox. Once you have ownership of the Exchange content, you can work through everything to determine what needs to be saved or managed, and in which location. Again, there are tools to help with this clean up, whether by using auto classification options or lifting content out of Exchange in bulk and transferring it to a SharePoint library.
- Use ‘in place’ Exchange management strategies for content that is really important, and you’re worried you’ll miss any management of it outside the repository it was created in. This strategy is a last resort, but still worth noting. While you can deploy the management of Exchange content directly in Exchange, you will lose the all-important context. On the upside, though, it will be managed! You can apply default management to an entire mailbox or use auto classification rules to identify individual emails that require specialist management. AvePoint Cloud Records provides for the management of in-place Exchange content right out-of-the-box and can be deployed in these situations.
While the suggestions above focus on actions you can take or support you can provide to users, it’s important that organisational process or policy is also reflected. What is the policy for the management of emails and how will this be documented, implemented, and communicated? When all those things have happened, how will the organization provide ongoing support to ensure users are maintaining the policy outcomes?
For me, in-place information management will always be my first preference, unless information context is at risk. Context is king. So if need be, I’ll turn to more creative solutions to ensure that context will remain, not only for the people creating the information, but also for those who might need access to it in the future.