Our organization is making the transition to SharePoint as our document management platform. I’ve read through the discussion board archive and seen that the consensus is that O365 retention policies and retention labels are incapable of providing a robust records management solution. I was wondering if anybody has actually tried to implement O365 retention policies and labels. I’m interested in what its deficiencies look like in action.
American Board of Pediatrics
Since I’m responsible for some of those comments you referred to, I suppose I should jump in here. Off the top, even MS doesn’t try to sell what exists with O365 labels and retention as “records management”. I’m pretty sure that’s because they don’t want 100% of ARMA and perhaps 30% (or more even!) of AIIM members climbing down their throats!
At this point in time, what O365 offers is a reasonable basic retention capability provided your compliance needs aren’t too complex AND you plan to move the large majority of all of your content into O365, including transitioning your Exchange environment to O365. If you need actual workflows for RM, need to manage content/data in other systems and repositories, need if/then/else rules-based policies (ex. if data is of type N1, and created in Maine, then classify under schedule A5, else classify A7 type of thing), need vital records capabilities, need to route to a historical archive, or a host of other aspects that, collectively, form the full corpus of RM, then you’re currently out of luck with O365. By the way, you can do all of that with RecordPoint and some of the other leading 3rd party solutions.
Now, if you have more simplistic regulatory/compliance requirements and/or you’re primarily needing more of an ‘information security’ type of solution, then, as the responses to this timely post on Linkedin talk about, you should be fine with O365 (though it can be a bit clunky to actually configure as one respondent mentioned).
So, as has been said many, many times on this board in response to all kinds of questions, it really depends on the combination of your needs and constraints (budget, resources, skill sets, timelines, processes, etc.).
Not sure if that really helped or not, but that’s my 2 bits for today.
I’d counter that it’s not whether the platform is capable of conditional assignment of records classification or not, it’s about how you think about it. If you use a workflow to set the classification it works just fine. It doesn’t, however, have the workflow integrated into the records management component, the assumption is that the generic workflow tools will accomplish the workflow needs.
Your point regarding the content needing to be in O365 is spot on. If you’ve got content other places, you’ll need additional tools.
Thor Projects LLC
Certainly an organization can find ways around some of the limitations using custom development in other tools, inside or outside of O365 (and Flow still counts as a minimal sort of custom development). However, that incurs technical debt. And while technical debt was something that primarily perturbed enterprise architects before “the speed of cloud” really became a thing, today I would posit that it is something any and every manager in any organization that wants to deploy technology should be thinking long and hard about.
SaaS (and PaaS to a generally lesser degree) solutions tend to change SO fast and on an ongoing basis today (two of the reasons to adopt them) that an organization that considers doing any sort of custom development against them should realize that in so doing they have just entered the software development business (to a lesser or greater degree depending). There are many use cases where that can make great sense. Maybe this is one of them. Depends on lots of factors I think.
I think that technical debt has become the new watchword that everyone has to use in their buzzword bingo. Sorry, but technical debt means things that should have been done differently which you’re not fixing. Calling the implementation of business rules in a flow tool technical debt is inappropriate in my opinion. It’s the same activity no matter which tool you use. It’s an implementation cost, not technical debt.
(By the way, the whole discussion about using InfoPath has me focused on not using technical debt incorrectly. See https://www.thorprojects.com/blog/archive/2019/08/15/using-infopath-today-not-just-say-no/)
I think that doing custom development is cause for concern. However, doing configuration of a tool is both expected and necessary. That’s what we’re talking about. We’re configuring the workflow tool to perform the work of our business. Will it need to be redone if you implement a different tool, yes. However, is it a debt? Not so much.
Thor Projects LLC
- Click to share on Facebook (Opens in new window)
- Click to share on Twitter (Opens in new window)
- Click to share on WhatsApp (Opens in new window)
- Click to share on Skype (Opens in new window)
- Click to print (Opens in new window)
- Click to share on Telegram (Opens in new window)
- Click to email this to a friend (Opens in new window)
- Click to share on Reddit (Opens in new window)
- Click to share on Pocket (Opens in new window)
- Click to share on Pinterest (Opens in new window)
- Click to share on Tumblr (Opens in new window)