Having trouble reaching your compliance requirements when handling federal records? Get your Ultimate Records Management Resource Kit today!
It’s natural to have questions when you’re thinking about moving to a hosted records solution for the first time. How do I prepare my environment for it? How do I translate what I have in legacy solutions to this new system? These are all natural concerns, and ones that I’ll touch on in this post.
There are the 4 key points everyone new to using cloud records should understand:
- In Place vs. Out of Place Records Storage and how the Cloud Records can help
- How a File Plan considers the different locations in the cloud where users might be declaring a record,
- What terms are and how they should be clearly broken down in a hierarchical format
- What a rule is and how it’s properly applied across the environment.
1. In Place vs. Out of Place Records Management
You first need to understand the methodology your organization has been using for records management. If you have used SharePoint as your primary Enterprise Content Management (ECM) system in the past, you may have heard of a “Records Center.” Historically, when you would declare an item or document a Record you would move it to an immutable state. The Records Center would be the place where all of these copies would have landed in SharePoint.
Free eBook: Best Practices Guide: Records Management for the Digital Era
If you used file shares or other legacy systems you may have marked that it was as a record and moved it offsite for storage, therefore doubling the space for keeping that content. On the other hand, you might have offshored it to a different system completely, and you might not have had a choice depending on the solution you were using.
This model of records management is known as “Out of Place” storage. While it has the benefit of localizing records, Important factors such as context of location, access depending on user roles, and unintentional recreation of that data may occur (i.e. a user recreates a document that was previously in a location because they were unaware the old copy was declared a record and moved).
“In Place” Records Management, on the other hand, is the modern take on the records dilemma. This is key when considering a move to a new system because this thought process may actually change your File Plan and the overall disposition schedule of your organization’s records. Do you currently keep your records in place or out of place?
Our record solution leveraging SharePoint allows us to keep all your records in place. You’ll thus be able to save on storage, more easily manage the content because you’re not duplicating its location, and take advantage of all the great search functionality and capabilities within SharePoint natively. We also offer the following options:
- Externalize the content if necessary
- Move it to a different location within SharePoint
- Export it into common records formats to allow us to integrate with other records services if we need to
2. File Plan Configuration
When moving to a cloud-based record system, you want to make sure that your file plan takes your new record creation platform into account. Previously, documents were likely the only kinds of records you had. When you’re moving to a cloud-based system like Office 365, though, you suddenly have access to structured SharePoint Sites, Groups (…which generate more SharePoint sites, yay!), and OneDrive. Will records live in these new locations as well? How will your new taxonomy align with your current file plan?
Keeping track of what kind of content will now live in SharePoint and OneDrive vs. file shares, Lotus Notes, and Dropbox accounts is extremely important. Understanding that your records management system of choice can see and act on these locations, though, is even more critical to your new strategy.
Now that have you have all of the potential locations for records to live figured out, what will be working in a new shiny in-place cloud hosted records system look like? Well, there are two big expressions that you’ll want to get comfortable with real quick: terms and rules.
3. What are Terms?
A term by AvePoint definition is the actual name or label that the record needs to be defined under. For example, let’s say you’re working with contracts. Those contracts might be a group of terms, and within that you might have statements of work, NDAs, MNDAs, Teaming agreements, etc.
Those individual labels are terms that you’re going to be using, and that’s what we’re actually applying as column values to your SP content. So, it’s important to understand that the language you’re using today will be translated into terms.
The “modern way” of doing terms if having them defined not based on the organization but based on the function. For instance, looking at my contracting example, we know that legal sales and HR all have various contracts. But I’m not going to set up my term hierarchy with “legal,” “sales,” and “HR” as the headers. I would set it up as “contracts” and just ensure that those sub terms of “NDAs”,” MNDAs”, and “Teaming Agreements” are used throughout the environment.
What would happen if sales and legal both have a different kind of NDA contract? You would end up with 2 different terms called NDA. It’s better to create a hierarchy for terms in a functional format. This way, the function of the document will be to serve as an NDA regardless of the organization using it at that time.
4. What are Rules?
But what is the criteria that allows you to understand when to apply these terms properly? Better yet, when does an item with a term applied become a “record?”
Let’s use our contracts example again. Say I have a document library for all the contracts used in sales. As they’re uploaded our Cloud Records solution will open a prompt to allow the end user to select the proper term that should be applied to this contract.
This is part 1 of a rule – identifying when a document should have a term applied. In this case we know that this document is a contract and needs to be tagged properly based on the document library it’s being uploaded to.
Once the term is applied, part 2 of a rule is to monitor that document with that term to determine when it should be declared a record. This could be for a number of reasons; maybe the “Created by” date has surpassed a year, or maybe another column in the document metadata has changed from “in-progress” to “complete.” Our rules actively monitor these documents with the criteria you’ve set to take action.
But what kind of actions can we take? Thank you for asking! We can:
- Simply declare the item a record and leave it in place,
- Declare an item a record then leaves a stub and externalize the content, or
- Move the entire document to another location.
The choice is yours! We’ve designed our solution to meet the needs of a wide variety of configurations.
So, what is your records strategy today? “In place” or “out of place?” Do you know where the records are in your environment?
Contact us at Sales@avepoint.com and we’d be more than happy to discuss!
Like what you read? Be sure to subscribe to our blog for even more great content!
