You are viewing limited content. For full access, please sign in.

Question

Question

Workflow Conditional Route if Template Field Values Match?

asked on May 21, 2014

I searched a little but didn't find anything similar to what we're trying to do so hoping someone has bult a similar Workflow process.

 

We receive LF Form submissions and one of the fields is a Member ID Number. I need to determine if this particular member already has a Laserfiche folder and if so, the LF Form gets routed to that folder. If the member number is not matched, then the document gets sent down a different conditional path in the Workflow.

 

The member number is a meta data field value and not part of the document name or folder name/path.

 

I might be over-thinking how to do this so hoping someone might be doing something similar and can describe how they went about it.

 

0 0

Replies

replied on May 21, 2014

All you should need to do is simply do a retrieve filed values of the incoming document.  Then do a Search Repository for a folder named Retrieve Field Values Member ID.

 

One branch would be for a result found.

 

The other branch would be for no results found.

 

I would also probably add a within folder search to the folder name search.  This assumes that these folders are all in a high level Laserfiche folder.

1 0
replied on May 21, 2014

Can you do a field search on the Member ID and then grab the first result and take its path?

0 0
replied on January 24, 2018

I'm working on a similar workflow to the one described here. I'm searching for a matching ID among employee folders and routing the entry to the first result path. Employees are divided into department sub-folders, i.e Department/Employee. On many documents, the route works correctly, but on some, the document is dropped into the department folder instead of the employee folder.

Adding the "track tokens" shows me that the first result name and first result id both match the correct employee, but the first result path displays the department folder instead of the employee folder. I have tried switching it to full path instead of path, but for the ones that previously worked, now they are getting a new folder created for the document because the correct employee was located at first result path, so it's going one step too far when switched to full path.

Any ideas what could be causing this?

0 0
replied on January 24, 2018

It sounds like you're getting both documents and folders in your search results. But it's hard to guess what might be the cause without seeing the workflow. Could you add some screenshots of your activities and their properties?

0 0
replied on January 24, 2018

Sure! Thanks for your help on this smiley

Here is the workflow itself. Basically we are scanning a document into one specific location. The first search locates docs in that location and performs the rest of the workflow for each entry.

First it retrieves the Employee ID from the found entry in the first search.

Second, it searches within a specific location in our repository for folders or documents that have the same employee ID. We have it set to return the first result, which should be the main employee folder. 

Here are the properties for that search:

Next we are retrieving field values from the folder found in the 2nd search.

Then we are routing the entry to the first result path and applying the retrieved field values to the new entry.

We are getting a lot of different results for path though. I was assuming that the first path would find the employee's main folder before it found sub-folders.

 

 

0 0
replied on January 24, 2018

It does appear to sometimes be finding documents within the employee folder and considering this the first path. If I delete the Employee ID from those documents, it will route to the correct location.

0 0
replied on January 24, 2018

Your search is looking through all the entries (folders and documents) under \Active. So you're getting the employee folder and all its documents. The order is non-deterministic, so your first result could be the employee folder or it could be one of the documents. If it's the folder, then the entry path ends with \Department. If it's a document, then entry path contains the employee folder too.

If you add a &{LF:Name="*", Type="F"} criterion to your search, it will return only folders.

Side question, though, why are you doing this as a search for new documents instead of using a starting rule for document creation? It's not going to be very efficient for large numbers of documents.

0 0
replied on January 24, 2018

I do have a starting rule set up for document creation, I just have it disabled right now since docs were landing all over the place smiley

I'll try the addition you suggested and post back.

Thanks!

0 0
replied on January 24, 2018

Hm, but if you're running on document creation, you don't need the first Search Repository and For Each Entry activities...

0 0
replied on January 24, 2018

True, I guess I was overthinking it during creation, but can drop that out.

I added  your criterion to the search and ran a test doc again.

Instead of going to the employee's folder, it dropped the entry into the department folder creating a new folder.

0 0
replied on January 24, 2018

First result name is correct...that is the employee I'm looking for.

But shouldn't the first result path have \Employee's Name?

Instead that's in the full-path.

Here you can see that it routed to the Sheriff's Office folder and there it created a new folder titled Benefits, where it dropped the entry.

0 0
replied on January 24, 2018

The path is the set of folders up to the one the entry is in. The full path is the path plus the entry name. So the employee's folder, "Barnes, Mark L - 330292006" has a path of "\Human Resources\Active\Sherriff's Office".

0 0
replied on January 24, 2018

Yes, but all of the ones that route correctly read "\Human Resources\Active\Sheriff's Office\Barnes, Mark L" for the path.

(Obviously with the correct employee's name--not Mark's wink)

 

I have been running this all day and almost all of them route perfectly, but this one and several others are stopping at the Department level like Mark's. I've checked every detail of the metadata, I've tried creating new folders for the employees in question, you name it, I've tried it....but still there are a few that will not go all the way to the employee folder.

0 0
replied on January 24, 2018

It sounds like those were the ones where the first search hit was a document and your workflow is set up to assume the path included the employee name. You can change the criterion in the search to &{LF:Name="*", Type="D"} instead of &{LF:Name="*", Type="F"} and it will only return documents.

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.