Search Repository test works, but not when WF is run normally

asked on May 7, 2018

I can't figure out why my Search activity works in testing, but when the WF is running normally, it does not find the target document. And yet, I have two search activities running in that same WF and the second one works every time! What am I doing wrong?

Target folders in LF:

The original submission is here: \LFForms\Website Report Form

The final form is filed here: \LFForms\Website Report Form\Follow Up

Search Querys:

Find the original submission (works in testing, but not in normal run): {LF:Name="*%(BP Instance Number for Final Form)*", Type="D"} & {LF:LOOKIN="flagstaff\%(Original Submission Path)", SUBFOLDERS=0}

Search Query to find:

Find the final form (which works every time!): {LF:Name="*%(BP Instance Number for Final Form)*", Type="D"} & {LF:LOOKIN="flagstaff\%(RetrieveFieldValueforLFFEntryPath_zLFF - Entry Path)"}

(both documents have this 996 Instance # in the name)

0 0

replied on May 7, 2018

When you say it works in testing, how are you testing it? Via the workflow designer or the laserfiche client advanced search syntax? When you search the workflow history, does it show 0 entries found when that search runs?

0 0

View 13 previous replies

replied on May 7, 2018 • Show version history

Testing via the Workflow Designer and the workflow history does show 0 entires found. The blue clips above are from the WF history on a normal run of the WF. The LF client search with the same data does work:

0 0

replied on May 7, 2018

Testing in the WF Designer results in a successful return of 1:

0 0

replied on May 7, 2018

ooo mysterious.

Can we try inserting the "Track Tokens" activity to make absolutely sure the token is being resolved correctly in the search string?

0 0

replied on May 7, 2018

I do have the Track Tokens in. Is there a specific piece of info that you are looking for?

0 0

replied on May 7, 2018

%(BP Instance Number for Final Form) and \%(Original Submission Path) are not built-in tokens, so I think Erik was trying to double-check that they have the values you expected them when the workflow ran. I'm not seeing either one in your screenshot above.

0 0

replied on May 9, 2018

Miruna, those tokens are working fine, coming up with what I expected. They are not in the grouping above, but I did cut and paste those results in the very first window post above. I didn't provide that in this latest clip because I was trying to show everything else that he might have been looking for.

I have also tested the search configuration of \%(Original Submission Path) both with the slash and without the slash to see if that was it. It didn't change the outcome. This part:

...{LF:LOOKIN="flagstaff\%(Original Submission Path)"...
...{LF:LOOKIN="flagstaff%(Original Submission Path)"...

0 0

replied on May 9, 2018

Is the document directly under the "flagstaff\%(Original Submission Path)" folder? The only major difference between your 2 searches is that the first one says its looking directly under flagstaff\LFForms\Website Report Forms, not in any of the subfolders.

0 0

replied on May 9, 2018

Yes:

And the other document:

0 0

replied on May 9, 2018

The other possibilities would be that the user specified in the Workflow connection profile does not have rights to see it. Or, given that Forms saves documents asynchronously, that your workflow runs before that document makes it into the repository.

0 0

replied on May 9, 2018

The original form comes in first. The final form comes in and the WF is prompted to combine the original form with the final form, rename it, and sent it off to the right file folder. So, it wouldn't be the timing.

Just checked the access rights to both folders and there is nothing different on them (all inherent to the very first folder, which is the LLForms folder). If it has access to one, it has access to both.

A real mystery!

0 0

replied on May 9, 2018

Do any security tags get applied to the original form?

0 0

replied on May 9, 2018

0 0

replied on May 9, 2018

Well, then it's probably time for a support case. But since the original submission is one document and you know both its path and its name, you could replace the search with a Find Entry activity.

0 0

replied on May 9, 2018 • Show version history

I'm pretty sure I tried the Find Entry activity, but there were too many variables still and couldn't get it to work. I'm trying to get this process to work on all forms that have a before and after piece that needs to be combined. They all have different names and different subfolders (approved, rejected, follow up, etc.).

0 0

replied on May 9, 2018

Actually, it is working on other forms, I just ran a test. It's only on this Website form that it can't seem to find the original.

0 0

replied on May 9, 2018 • Show version history

The searches are run first. Then, the form goes through a Conditional Decision branch to determine which type of form this instance is so it can file it in the right topic folder. The website report ones are terminating at this conditional branch because the search activity found no original submission, yet the payroll deduction one worked and combined the two pieces. And all the forms are set up the same way, with the BP ID# (to match the right ones) and the path in a field for look up (to match the right type of form).

Different types of forms:

0 0

This is the one that works (see below). See how close the two of them are? I've compared everything. The one not working did originally have the same token as the working one (...retrieve values..) and configured to remove the last folder properly, but it didn't work either. That's when I decided to try a separate token to come up with the original path, but nothing seems to get this working.

Both the original and the final form have the same BP instance Number in the name.

Question

Question

Search Repository test works, but not when WF is run normally

Replies

Sign in to reply to this post.