Using workflow, how most effectively declare when a document becomes a Record?

hello,

NOTE: this isn’t a policy question about when a document becomes a record

How, meaning by what mechanisms–most effectively using workflow, while also considering human/user behavior pertaining to storing/“managing” their own documents–is a document declared as a Record? What I mean is at the point at which a document becomes a record–the point at which a document is formally declared to be a Record, moved out of editable working format, if it had been changeable/editable previously—how is the declaration of a document as now a Record best accomplished if, as suggested in today’s awesome class, users simply put everything in folders by the same topic, content/document type, or business function?

Again: not a policy question about when a doc becomes a record. It’s presuming your org already figured that out. It’s how–by what processes–would you declare a doc a record if everything, whether a document or a record, is simply put in folders by users. That some records types are documents that at some stage become official records.

Also: not really a software-dependent question. Process question more than anything.

Note: in Nevada, where I am, drafts are not considered public records.

Hope that’s clear :slight_smile:

Thanks!
Susan

Hi Susan,

Great question. This gets at the heart of what Feith Systems (RMU’s sponsor) does as a company, and why we’ve been popular for going on 40 years now.

I know you said it’s not really a software-dependent question, but I would disagree.

I think that knowing what kind of metadata you have attached to the documents and folders, and also knowing how the documents got there, what are the formats of those documents, and so on, will dramatically change your answer.

It also depends very much on what kind of Records Management and Workflow software you actually own. If you’re using something like Feith’s software platform, where you can interrogate the contents of the documents programatically, that will give you a very different answer than if you’re trying to solve this by mere scripting or a very basic workflow product.

We also have to have more knowledge about what kind of records end up in these folders – what departments are using them, how many categories are likely to be involved that we need to sort between. To answer the technical question, one would also need to know what percentage are likely to actually be records given the policy of your org, and what is your organization’s risk tolerance for false-negatives and false-positives.

Actually applying workflow to your real-life records repository is where Records Management crosses from a risk/policy concern to an actual applied science.

The very short answer to your very big question is: Well, that’s we do for a living!

To circle back around to the beginning – what does the data look like? Where is it stored? What does the metadata look like? What file formats? How did it get there? Do you have a Records Management platform? How many categories are involved? etc. These are the first questions needed to tackle that kind of problem.

Richard

1 Like

I’ll kick the tires here. There is no law that states you must declare a record for it to be a record. That shows itself in the subpoena which states ‘relevant material’ but never ‘declared records’. A lot of the stuff created is not important or a benefit to an organization long term. You need to understand what records are important so they can be managed and able to show they are ‘trustworthy’ and ‘authentic’. Lots of systems with ways to do that and your Legal group will be happier. It is a fact, that the issues of ‘trustworthy’ and ‘authentic’ almost never come up anymore in court but your Legal folks will err on the side of caution for key records.

Why is it a rare topic in court? Technology. Today’s tech can find the metadata and changes to the metadata to show manipulation. A Word doc I believe still has between 600-800 possible metadata points inside of it. Manipulating TB’s or GB’s of docs is too costly and time consuming for companies. When manipulation is found, it is on a very small set of records. Then in the USA, there is the Federal Best Evidence Rule. Basically, it’s what we use and all we have your honor. Lots of leeway there in court. It is even rare now for a judge to tell the jury that evidence will be accepted but not to trust it too much.

Of course, what you produce for regulatory agencies must conform to their code. But, even there, the code does not state ‘declare’ it a record before saving or sending it to us.

2 Likes

Thank you, Richard. I totally understand how a question like this could result in a “it depends” answer : )

Thank you for laying out some of the considerations you see as factoring into figuring this out.

Although, I don’t totally agree that The Answer to: How most effectively to declare a document a Record using workflow when users manually store/organize all similar content in folders is “Well, that’s what Records Managers do for a living,” I see where you’re coming from.

Thanks again,
Susan

In reviewing this more, I think I may have misunderstood your question a bit.

I understood your question as being: “how does one, using a workflow software package, create the logic which identifies records?”

But it appears your question is actually more like, “so you’ve determined something is a record, what do you do with it?”

Is that correct?

1 Like

Would this be a case of a “working copy” vs. an “official copy”? If so, I would say this would have to be built into the business process, i.e., official copies are placed in the document management system vs. kept on the employee’s desktop. I would think this is more to do with training the employee to identify what constitutes a record and then where to put it once it meets the criteria. I am struggling with the same question, but that is what I have been able to come up with in my logic. Flawed logic, perhaps? What do you think?

1 Like

hi Adrienne,

Thanks for your reply.

Very close to our situation, although our policy/practice is that all working documents live in our enterprise documents management system, rather than shared drives or individuals’ desktops. And, incidentally, our documents management system has a records management component to it that hasn’t yet been activated.

I was interested in the statement in the University class this week, which I interpreted to be suggesting that a retention schedule can be activated through automated workflow in a records management system, and I wondered how that could be possible when, as I thought was mentioned in that statement in class, users are storing multiple types of documents (all associated with one business process, for example) in one folder. Maybe I misunderstood. I’m somewhat skeptical that an automated workflow can “know” when something becomes an “official copy,” aka is declared as a record.

It seems it has to be a semi-manual process–unless there is a trigger that’s associated with the workflow in another system OR if it a document automatically becomes an official record after x period of time after it is created (which I can’t come up with a use case for).

I can imagine there could be a workflow in, say, a project management tool that would be connected to a documents management system, and upon X phase or action taking place (which would serve as the trigger event) in the project management software, a workflow in the documents management system would either kick off a retention period “clock” on those documents that had already been earmarked or defined as potential records–and that document would remain in that same folder in the documents management system–or would be moved to a records management system/platform/tool—but now identified as an official record.

But that’s where I could be missing something - are there other ways that “workflow” alone–in records management software–would be able to distinguish among multiple document types, if they are not forms, templates, or contain unique key terms or language or formatting? As said, maybe I misheard that being said in the Records University class.

So, I’m thinking along the lines of what you’re thinking, Adrienne–that this is something that has to be baked into the business process and staff trained to do x,y,z at least partially making it a manual process.

Open to lots more discussion! Thanks for all replies so far.

Susan

I can imagine there could be a workflow in, say, a project management tool that would be connected to a documents management system, and upon X phase or action taking place (which would serve as the trigger event) in the project management software, a workflow in the documents management system would either kick off a retention period “clock” on those documents that had already been earmarked or defined as potential records–and that document would remain in that same folder in the documents management system–or would be moved to a records management system/platform/tool—but now identified as an official record.

Yes, exactly. Unless you’re doing manual retention, or your automatic retention is based on creation date or date of last modification, you will need to provide information about the real world to your platform. That’s easy when the process lives in that same system.

For example, let’s say that you’re keeping all of your company policy information in your document management system already, and you have the policy status (approved, cancelled) marked in a column of metadata in that system, then using that column of data to inform your records workflow for policy document retention is simple.

It can be a little more difficult when you need to pull that information from an external system.

For example, if you are identifying in your file plan that you’ll maintain employee records kept in your records system for XYZ period of time after separation, then you’ll actually need to know when an employee has separated – this is usually going to be a simple integration with your HRIS to pull in that kind of basic employee data.

Building all of that out is exactly what I meant when I said: “Well, that’s we do for a living!”

That’s the business of being a Records Manager in 2018. The policy/IT cross-discipline involves you doing a lot of IT work to get the information you need, in the place you need, in the format you need, and then analyze it from a policy standpoint so that you can workflow around it. It’s no small task, but it can be done.

Well stated Richard. There is certainly more possibilities in today’s applications to remove the human element. I believe the ‘interoperatibility’ of systems will improve as the weight of data created and the need to manage it, pushes for more open source and easy to access api’s at the least. The world of end-to-end proprietary coding will have to (and is slowly) give way as businesses are becoming less tolerant of them.

1 Like

Great point. The interoperability is a very big deal.

You’re right that if the market moves to more common data models, that will take quite a bit of the difficulty away.

We’ve seen that in two examples:

  • The OPEN Government Data Act of last year, which passed both house and senate, required that all government financial data follow a uniform machine-readable data model. What it means is that it will become possible in the next few years to easily get a view of all of our Federal government’s financial information, since once you’ve captured and dashboarded on one set of this data you can dashboard all of it. (https://www.datacoalition.org/open-government-data-act/)

  • Another example, in Pharmaceutical safety tracking software, which is one of Feith’s other core lines of product, there is a data model that is universally accepted for the data. It’s called E2B R3, it was made law by the EU health authority, and it defines exactly how the health data should look (XML based). What that means is that Feith can connect to just about any drug safety system that supports the model and pull the data from it, or push data to it, with very little configuration.

The thing to note in both of these cases is that it was the government that initiated the common data model. It remains to be seen to what degree the private market will also come together to create common data models, since there is a perceived financial incentive not to share with your competitors. Going back to the HR example; does SuccessFactors want to make it easy for WorkDay to pull their HR data out? If the government pushes for more common data models, that could alleviate the issue in some spaces but it does create a whole new host of issues.

The other alternative is services like our partner Active Navigation. Their core business is creating interoperability between data and document repositories, pulling information from those repositories, and cleaning out the ROT. So, if our Records Management platform is being bought by a very large entity that has tens of legacy document management systems, for example, we’ll bring in Active Navigation to connect to all of the different systems, and they pass the data to us. (http://www.activenavigation.com)

We’re also seeing vendors try to create those kinds of interoperability systems with consumer application interoperability layers like “If This Then That” (https://ifttt.com/), which is a service with built in connectors to hundreds of different consumer apps, so you can push data between them. It’s only a matter of time until a serious offering of that kind is available for the Enterprise, and vendors like Feith will certainly be racing to partner with companies like that as they become mature.