Christine, thanks for reaching out!  This is a huge topic and full of ... difficult concepts unless you are already fully experienced with this type of electronic records management software solutions.  It took me awhile to get to the place where I felt I understood properly and, yet, another Alberta municipality that I am in touch with alot for which I admire their professionalism in how they are developing their LF understands the explanation of TRM differently than I do.  My understanding is that it is just the folder structure where your staff can see their records (actually only shortcuts) yet in truth the actual records are hidden in Record Series folders where they are in different folders according to their retention.  This other municipality sees the term TRM as more than just the folder structure but the entire process (including the automation) of how they get their records from the staff folders to the right Record Series.

To make this WAY, WAY easier for our office, in the end we decided to let staff move their records into their folder structure throughout the year and only pull them (leaving behind shortcuts) at the end of each year.  This way, they have a whole year to work with the records, since they often would go back and add pages or delete a copy that was not fully complete and replace it with a scan of their newly corrected or fully completed records.  This is when we were still fully using old paper processes and scanning at completion.  And, if the records are considered "Permanent", they are not pulled at the end of the year.

Over the years since our first year of trying to get set up (2014), we have changed a fair bit and added a lot of automation.  For instance, staff now puts their records into folders that have hidden metadata on them.  Some of that metadata sets triggers for whether or not to archive (pull at the end of the year), some of it is for the retention expected for the target documents in the folders, some of the metadata is triggers for whether the records in those folders are Event based and therefore should not be pulled until the Event is closed or otherwise completed.

Currently, we have numerous workflows that take records from the staff folders and move them to a holding folder for me to verify retention and then place in the right year's Record Series retention folders, however, I have recently realized that with a little more planning, I could even have workflow place them in the Record Series folders and then every so often go into those folders and double check retentions on them.  Haven't decided to move on that plan yet.  In the meantime, this is what some of my workflows for retention do (see below).  Keep in mind, every reference to "archive" is really just referring to the movement of records from staff folders to Record Series folders.

Overview of Archive Processes 

WF1 – “Archive a Document” 

• This WF runs all year long.  Any document dropped into the Archive folder will start this WF, which will remove the document to Record Series immediately, with no shortcut left behind, and will also add the word “…ARCHIVED” to the end of the document’s name, and will add a “Date Archived” field.   

• The folder the documents go to is called, “RECORD SERIES - Archive (incoming)” and the LF Administrator will then need to move these documents into the right Record Series folders, depending on how long we are required to keep the records (referring to the current Retention Schedule). 

• We could also have the WF add a watermark (Archived) if we want, however, at this point the watermark is not being added. 

WF2 – “Set Retention on Documents”  

• This WF runs all year long.  It will set the field called “Retention Plan for this Document” on every document, immediately upon it being placed in a folder, based on the metadata set on that folder.  

• Each time a document is moved from one folder to another folder, this WF will activate again and attempt to match the metadata on the document according to what is on the new folder. 

• Some folders hold documents with mixed retention expectations.  Those folders are currently being left blank for this metadata. 

• This WF is setting up for WF5, which controls where the documents end up in the archive sorting folder called “RECORD SERIES - Archive (incoming)”.  

WF3 – “Set Archive Tags December 25th”  

• Every folder has a field that is set to control what happens with documents at the end of the year.  Do they get archived, or do they not?  Does the staff need a shortcut left behind, or do they not? 

• On December 25th, this WF will search out every folder and decide whether to set an archive tag on the documents, based on what choice was set on this metadata field. 

• This WF is setting up for WF4 which will do the actual work of pulling all the right documents (by looking for these Archive tags) into the Record Series folders where they need to be set up for proper retention. 

• WF3a – “Remove Archive Tags on CURRENT” – At the end of WF3, another WF is invoked to go through and double check to make sure we didn’t accidentally tag any CURRENT documents (See Procedure called “Laserfiche Procedures - Special Documents” for more information on this type of document.) 

Note:  January 2020, WF3 was instructed to not tag any documents with CURRENT on the end.  The WF3a was left in as an additional catch-all in case something did end up with the tag on it anyways. 

WF4 – “Archive (Mass Archive on Dec 31st)” 

• The Mass Archive workflow will search out documents tagged with any one of two Archive tags, leaving shortcuts behind where it finds them (depending on which Archive tag it finds).  The WF will remove the tagged documents to the archive sorting folder called “RECORD SERIES - Archive (incoming)”. 

• It also removes the tags and renames the documents with the word “Archived” at the end of the names. 

• It also records the original path on the moved documents by putting that path into a metadata field called “Original File Path”. 

WF5 – “Move Archived Documents to a Retention Folder” 

• This WF looks at every document brought into the archive sorting folder called “RECORD SERIES - Archive (incoming)” and files them based on the metadata in the field called “Retention Plan for this Document”.  

• This will mean that when the Archive processes happen at the end of the year, a large majority of the work the LF Administrator must do (in January) in sorting documents for the Record Series will already be done.  This is a significant saving of time for the LF Administrator. 

This is an interesting topic to me.  

I have been having trouble reconciling TRM and RM.

Is there an in depth training on this?  I have watched some already, but did not gain an understanding.

I am thinking although we have the TRM module we may not really need it?

Can anyone provide more real life examples of why we need it?

Sorry to be so dense.  Any info helps, and could provide the key that unlocks my brain around this topic.

Thanks!

Christine

Chris, thoughts after your last post:  So much info!  LOL  Thanks!  

In answer to questions you posed:

"...require users to use custom searches...?"  I did create some Saved Searches I thought they would find useful (pasted them in all the users attributes), but I don't think my two test pilots have been using them.  I didn't think of trying to make them mandatory.  (and YES!  My users are scared to death of using the search tools, as well!  Seems to be a big hurdle for them.  They especially don't like having to Reset after each unsuccessful try (reset, so it's not just searching the new criteria within the results of the previous search).  Just discovered a few short vids LF offers for new users that  might help:  One called Laserfiche Quick Search and one called Getting Started with the Folder Browser).

"...have you tried adjusting folder access to block..."  or  "...deny rename..."  or  "... deny access to change metadata..."  I've only blocked them from deleting, or moving folders (in order to enforce locations); the documents are considered theirs to use, then archive or delete as necessary.  Training will be necessary so they understand what they're allowed to delete and what must be archived.  If, after the first year we find they are deleting things they shouldn't, we may adjust our policy on this.

"...more info on our users..."   Two users currently (test pilots).  Had to insist they put all their docs in LF before they began using it enough to be good test pilots.  There seems to be a default back to using the G: drive when they're uncomfortable with the new steps in LF, so had to insist all docs come in and be deleted off G: drive (it's our end goal, anyways).  We have 35 more staff to be brought in; one dept at a time will be brought in with a deadline of ___ days to get all their docs in before they are locked out of G: drive.  We expect to have one designated scanner per department eventually.  Haven't begun the pre-planning work with the dept staff yet.  Will start pre-planning with depts once BP's have been designed and are working for test pilots.  I've chosen the legislative assistants and finance dept as my two key areas to get BP's working for before bringing in any other dept.  Next will be getting Human Resources BP's set up and working.  Once those are all working nicely, bringing in the remaining depts will be a snap!

"...mini map of WF..."  Wow!  I don't have anything that complex yet.  I've explored creating and using tokens, but am not proficient with it yet.  Hoping to get more practice in soon.  Printed yours off for more study down the road.  Thanks!

As far as your "Doc Import" processes and metadata/renaming WF's, I've explored those ideas over the past months but haven't settled on anything concrete yet.  I've started a WF that will Move a doc based on Template, but haven't got it working 100% yet; plus, we are concerned about staff choosing the wrong template so we're exploring ways to assist staff in choosing the right template (see my posts in LF Answers looking for help on these).  Need more time to get these two projects completed, plus I think I might have a better idea how to complete them after a training session I have set up for this Wednesday.

"...considered using Business Processes..."  Hell, ya!  ;)  I have a ton of plans set aside for creation once I have enough training (my first solid BP will be created with our VAR this Wednesday, using a Contracts renewal process as a training session with him; we will be working on it together).  Two projects started already; have been put on hold until I get more experienced:  Service Request process to be launched on website for the public and staff to use (created in LF Forms) and Draft Agreement process (using WF & BP's, mapped out using LF Forms).

Connie (Flagstaff County, AB)

I have designed our repository (and workflow creating shortcuts) the same as Greg, however, we ran into issues.  Staff would do a search and, even though they couldn't see or use the RS folders, the documents would come up in the searches.  They have to have access to those documents; that's what the shortcuts are all about, but is causes confusion and clutters up the search window.  I was planning on training heavily weighted on doing searches for "shortcuts only", however, we ended up discovering more serious problems with this design and we have now restructured completely.

Problems:

1)  Staff would copy a shortcut and paste elsewhere, rename the shortcut (thinking they are renaming a new document) then go in and change what they thought was a copy of the old document.  They were overwriting their originals, losing critical data.

2)  Staff were extremely confused by where the actual documents were located and even the simple steps of opening the document and hitting Save As to create another document became problematic.

Solution:

1)  We got rid of all the shortcuts and put the documents back into the staff folders, except for those documents that could already be considered archived (permanent records, never to be changed, like copies of approved bylaws, policies, business plans, etc.)

2)  Some of the "working documents", once approved by Council, would be pdf'd and archived, leaving behind the Word doc (for example) in the staff folder for use in the next version of this type of document.  The LF Versioning tool will be used in many cases, but not all.

2)  Staff will have to add a tag (called "Archive Document") to any and all documents they consider now finished and ready to file away.  A workflow will then take away the document to RS.  (There is a second tag they can use for this if they want a shortcut left behind.  A second WF will act on that tag with the only thing different being it will leave behind a shortcut for them in the originating folder.)

3)  Staff may not remember to take this step when finished with docs, so another WF will be created to search out docs not opened for more than 6 months (or maybe a year) and report those to the departments, asking someone to review them and determine if any of them should be archived.

Chris Cartrett:  If you have any processes or designs to share, I would love to see them!  We, our LF implementation team, have the opinion that we shouldn't have to re-invent the wheel, so to speak; considering that we are all municipalities working on processes that should be very similar.  There should be a place we could go to see samples of what others have done (including samples of the design, details of the wf's, how they were put together, etc).  This would give us a head start with implementation and result in less frustrating experiences.  Good for you for starting this thread!

We pretty much use TRM for everything, even documents that have no need of formal retention. It's saved us some headaches in making changes. It's nice to be able to delete an entire folder tree and regenerate it into a different structure as requirements change.

We have some cross-department records access as part of our accounts receivable process. Finance owns the Records, but we generate folders and shortcuts within each department's folder structure specific to that department's documents. We have a business process that also crosses department lines. When the document is initially scanned, it gets stored in a Records Series. As it works it's way through the process, the shortcuts get moved around to various people who need to act on them. Eventually there ends up being shortcuts to the documents that are relevant to each department in that departments folder structure.

Hi Greg,

I see what you are talking about here. A couple of solutions come to mind. One is to restrict those employees who are members of the credit union from using client based searching and instead use WebLink as an intranet for document viewing only. If you use WebLink, you can define the custom search criteria to only retrieve shortcuts from a defined folder location.

Here is an example of how I use custom weblink searched for our public portal. Here I have a defined search pointing to specific folders only.

The other option I am thinking of would involve the use of Workflow. If you have a table with data telling if your user is a member of the credit union, you could have workflow 'assign rights' for each of those documents to restrict access to that individual user. That being the case, the individual user could retrieve the document in a client based search, but would be stopped upon trying to open the entry.

Does any of this give you an idea or I am just shooting blanks here?

I'm in the initial stages of implementing TRM for all of our member records (we're a $1B Credit Union).

I have workflows built to move documents into RM as they are captured, and I have prepared a workflow to migrate approximately 3.5 million documents from the general repository area into RM.

One issue that has held up that roll-out (I posted about this in a couple other LF Answers threads) is document security.  Documents in RM can be found in search results even though the shortcut to them is in a secured location.

I'm trying to determine how I maintain the security in force on the shortcut to the document in RM as well.

The main reason for this is employees who are also members of the credit union.  Their member records are stored in repository folders with limited access.  When those documents are moved to RM, the limited access doesn't follow.

Any thoughts would be appreciated.