Question

Metadata Field to Allow Selection of a LF Folder

Laserfiche Workflow Business Processes Ideas

Updated February 6, 2017

asked on March 31, 2014

I'd like to be able to specify where I want Workflow to move a document at the end of the process (because it changes depending on the document). Would it be possible to provide a metadata field type that offers a file picker that would display the LF folder structure?

0 0

Answer

SELECTED ANSWER

replied on March 31, 2014

That is possible, but there's not a way to populate the metadata field with the folder data automatically. You'll need to manually populate the list field with all the folder names and either create a branch for each folder or use tokens to avoid multiple branches.

Another option that you may want to consider is to set up a metadata list field of "Document Type" and set up a workflow that routes the documents to the appropriate folder based on the document type.

0 0

Replies

replied on April 1, 2014 • Show version history

Hi Susan,

If the requirement only requires one, two or three levels of folder structure, I might have a solution. Dynamic fields, which use the Laserfiche folder structure as their source, can be created.

The solution I have in mind could work with many levels of subfolders but the template gets a bit large after three.

The first step is to mark the root level for the folder structure. I use "Folder Filter Expressions." Setting the expression to something benign like "1=1" won't affect the operation of Laserfiche but gives the code something to look for.
Create the view below:


CREATE view [dbo].[3LevelDynamicField] 
as

SELECT convert(nvarchar(40),t1.name) as [Level1], 
  convert(nvarchar(40),t2.name) as [Level2], 
  convert(nvarchar(40),ISNULL(t3.name,'')) as [Level3]
FROM toc AS t3
  inner join toc AS t2 ON t3.parentid =t2.tocid 
  inner join toc AS t1 ON t2.parentid=t1.tocid 
WHERE t1.filter_expr='1=1' --This is the folder filter exression that marks the root folder
  and t1.etype=0 and t2.etype=0 --Just folders are required
  and (t3.etype =0 or t3.etype is null) --the "is null" check isn't required for this variation of the script.
  and t3.toc_flags & convert(int,0x800)=0 --Exclude items in the recycle bin

The script above creates a database view which can then be registered as an External Table in the LF Admin Console and used to create dynamic fields.

-Ben

1 0

replied on March 31, 2014

So there is no way for you guys to create a metadata field that would act like a folder picker in an application? We have hundreds of folders so creating them manually would not work for us nor would filing based on document type.

0 0

replied on March 31, 2014

The only available types for metadata are data types. A folder picker is more of an object, like something you would add to a custom application. Maybe there is another way to solve the problem.

How are the documents being created, or where are they coming from? Scanned In, Dragged In, etc.

What are your starting rules for the workflow?

If the route location changes depending on a document how will it help to choose a location manually to begin with?

0 0

replied on March 31, 2014

Chad's right on this. I realize that sometimes it's not possible, but I would recommend against creating lists of folders in order to get Workflow to file documents. Instead, build your metadata in such a way that Workflow can use the metadata to find the appropriate folder. It's a subtle difference, but an important one.

It's like giving someone turn-by-turn directions to a destination vs. teaching them how to read a map and plan the route themselves.

1 0

replied on April 1, 2014

I see your point. In this case I ended up just creating a single field where the initiator of the process can copy/paste in the correct folder. There are hundreds of potential folders that are 2 nodes down from the root. After that, there are still several nodes to go. The user would have to supply all this information in separate metadata fields that end of the day would not be that useful individually from a search standpoint. Seems to be easier for them to just specify this one value.

But ... we are pretty new to LF so I am sure we are not doing things the most efficient way. I'll keep an eye out for more opportunities to use metadata fields for things like this.

0 0

replied on April 1, 2014

Thanks, Ben, for taking the time to post this. There are typically 7 levels needed to file these properly. I'll keep this code in mind, though, as it may prove helpful for other situations.

0 0

View 3 previous replies

replied on April 2, 2014 • Show version history

Hi Susan,

No worries. Also, seven can be done with the above script (see below).

In general, any folder structure more that three levels deep can usually be rationalised and seven, more so. Especially if it means reducing the number of fields to complete.

CREATE view [dbo].[7LevelDynamicField]  
as 
SELECT convert(nvarchar(40),t1.name) as [Level1],  
  convert(nvarchar(40),t2.name) as [Level2],  
  convert(nvarchar(40),t3.name) as [Level3],  
  convert(nvarchar(40),t4.name) as [Level4],  
  convert(nvarchar(40),t5.name) as [Level5],  
  convert(nvarchar(40),t6.name) as [Level6],  
  convert(nvarchar(40),ISNULL(t7.name,'')) as [Level7] 
FROM toc AS t7 
  inner join toc AS t6 ON t7.parentid = t6.tocid
  inner join toc AS t5 ON t6.parentid = t5.tocid
  inner join toc AS t4 ON t5.parentid = t4.tocid
  inner join toc AS t3 ON t4.parentid = t3.tocid
  inner join toc AS t2 ON t3.parentid = t2.tocid
  inner join toc AS t1 ON t2.parentid = t1.tocid  
WHERE t1.filter_expr='1=1' --This is the folder filter expression that marks the root folder you want to use 
  and t1.etype+t2.etype+t3.etype+t4.etype+t5.etype+t6.etype=0 --Just folders are required 
  and (t7.etype =0 or t7.etype is null) --the "is null" check isn't required for this variation of the script. 
  and t7.toc_flags & convert(int,0x800)=0 --Exclude items in the recycle bin

0 0

replied on January 31, 2017 • Show version history

Hey Ben, is there a trick to registering this view as an External table?

Nevermind, I had to restart the LF Server Service and then it registered successfully.

0 0

replied on January 31, 2017

Hi Shaun,

No trick required. It's just a standard SQL view. What did you name your view? Are you getting any error messages?

-Ben

0 0

replied on January 31, 2017

Hi Ben,

After restarting the LF server service it registered fine. However, my view is empty. I ran it on the Laserfiche DB. Was there anything in your code that had to be changed?

0 0

replied on February 1, 2017

Hi Shaun,

If the view works in SQL then it should work in Laserfiche. I sent you a message with my email address offering some help. Alternatively, we could catch up at Empower.

-Ben

0 0

replied on February 6, 2017

The example SQL, above, assumes a set numbr of folder levels and that documents only go in the deepest level. It was made with the idea of a functional hierarchy in mind - function, activity, transaction - with all documents at the transaction level. Also, the point of using the folder filter of "1=1" (rather than an entry id in the script) was intended to give an LF admin the ability to determine which folders ended up in the lookups.

It doesn't work with a file series and it doesn't work with mixed levels of folders.

If anyone needs a script to work with folders and file series, and that works with a folder struture of mixed depths, let me know. I have a new script for that.

1 0

You are not allowed to follow up in this post.

Question

Question

Metadata Field to Allow Selection of a LF Folder

Answer

Replies

Sign in to reply to this post.