Question

Move Entry, moves folders instead of documents

Version 9 Workflow

Updated July 16, 2014

asked on July 16, 2014

I have created a Workflow that works great... it moves documents out of the staff interface into a designated Record Series folder and it leaves behind a shortcut for the staff.

Only problem is, it doesn't always do it. If the document is moved it does, if the document is created by drag-n-drop from out of LF it doesn't. I need it to do both (either/or), but WF doesn't give the option for both! Creating a second identical WF but this time with Event Type being Entry Created gave me two shortcuts.

In the meantime, I'm working on creating a Workflow to pick up any documents that the first WF doesn't pick up. I'm in test mode and so far it's not working quite right. I've attached some printscreens from it, including some of the results from the attempted run. Questions:

1) Why does it move the whole folder instead of just the documents?

2) Why does the shortcut end up at the parent folder instead of the original entry location?

3) Why was the shortcut step looping (created over 3,000 shortcuts before I could stop the WF)?

After stopping the loop, I changed both the Move Entry and Create Shortcut steps to terminate if the path does not exist, which helps but I need to resolve the questions. Please help this newbie with these basic steps. :)

Troubleshooting the MOVE DOCS TO RS workflow.docx (1.06 MB)

| Download

0 0

Answer

SELECTED ANSWER

replied on July 16, 2014

Hi Connie,

First, you should not need to create a second workflow, you can add a second starting rule to your first. In this case you have a starting rule for Entry Moved, so you can create another for Entry Created. To better see why conditions are being evaluated as they are, you can open the Subscriber Tracer in the Workflow Admin Console. It shows you events the subscriber picked up and how and why they were evaluated the way they were.

As to your other questions:

If it is moving the folder instead of the document, my guess is that the starting entry is the folder, so the workflow is treating that as the entry. This would also explain why you are getting the shortcut to that folder.

For the runaway workflow: this workflow is triggering itself. It is a best practice to exclude your Workflow User from the starting rule to avoid a workflow from infinitely invoking itself. I'd recommend looking into starting rule best practices more here.

Hopefully this helps with both issues, but ideally you shouldn't even need the second workflow.

0 0

replied on July 16, 2014

Oh, excellent! Matt, that was exactly the type of hint I was hoping for. I didn't realize you could have two separate starting rules like that. I've built it and tested it and it works! I have deleted both of the other extras that I was trying to use to catch the ones the first ones missed!

As for the other three questions, I'd still like to find the answers for building WF's in the future.

a) Yes, the starting entry is to find the folder at a specific named original location. And it did find it and move it. The Move Entry activity didn't allow me to say move the documents only (that I could find) and I knew that was probably going to be an issue but couldn't find a way around it.

b) The Create Shortcut activity didn't allow me to say "leave the shortcut at the original destination" however, I copied the create shortcut activity from the WF that was doing it right and double checked that it saved the settings right, but it still wanted to save in the wrong location.

b) I'm pretty sure I had the User does not equal WF rule on that one and this is the second time I got a loop going even with that starting rule. In this case, I would have thought that once the folder was moved, it couldn't find it again because the starting entry was no longer there, having been moved by the previous step. It was the shortcut that kept being created over and over, even though the actual folder was already moved.

0 0

Replies

replied on July 16, 2014 • Show version history

For starters, your first screenshot is showing an Entry Moved event type. When you drag a file into Laserfiche, that's a created event.

Some observations about your other workflow:

The move entries activity is working on the Starting Entry. In this case, what is the starting entry, and why aren't you pointing it at the results of the Find Entries activity?

That brings up another question, you mention loops, but there aren't any in the screenshots. When you do something like the Find Entries activity, you need to include a For Each Entry loop and put the Move Entry's inside.

I'm not sure how a Move Entry activity could loop like you describe unless it were inside a loop.

0 0

replied on July 16, 2014

Thanks, Devin. I've found the real solution, but would still like to find answers to the original questions.

You mention pointing the Move Entry at the results of the Find Entries activity. How would I do that? It allows me to pick the destination, but I thought it was operating already based on the Find Entries result.

And your comment for including a For Each Entry... right! I forgot about that option. I need to remember that for next time I'm working on one of these. I should have known that, I did a practice training session using that activity.

The looping is still a mystery to me.

0 0

You are not allowed to follow up in this post.

Question

Question

Move Entry, moves folders instead of documents

Answer

Replies

Sign in to reply to this post.