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

Question

Question

Workflow stopping on a branch even though classification is not missing and all fields are filled out.

asked on November 12, 2019

Hello all, 

One of our clients has a workflow that is erroring out on a branch, although the classification is not missing and all appropriate fields are filled out. They had a similar issue with a different workflow but it was fixed by disabling the conditional decision, creating a new conditional decision, then republishing. Unfortunately, all invoices that were running the old workflow had to be deleted and taken through the process again with the "new" workflow, in order to be processed. 

Has anyone else encountered something similar? If so do you all have a different/simpler fix or a explanation on what can cause that to occur? 

 

Any insight would be appreciated!

0 0

Replies

replied on November 13, 2019

What do you mean by "erroring out on a branch"? The orange overlay on the screenshot makes it hard to tell, but that looks like a workflow that successfully completed due to End Workflow 7.

0 0
replied on November 13, 2019

Hi Miruna, 

Apologies for the orange overlay, typically the workflow would stop on the branch if the classification field was empty. In our case the document had the appropriate field filled out so it should not have even stopped at the conditional branch and should just have continued as normal. This has been happening for documents even though the classification field is not empty. 

Thank you,

0 0
replied on November 13, 2019 Show version history

The instance details should show you what the values were when the condition was satisfied. But that Conditional Decision looks to have an End Workflow activity in all branches except for the last one. So if any of the first 5 branches are hit, your workflow is designed to stop after this activity.

0 0
replied on November 13, 2019 Show version history

The user ended up creating a copy of the conditional decision and disabling the current one and republishing. We ran a test document and ensured that it did not satisfy any of the conditional decisions (ensuring field is not missing, proper template, etc.) but the document stopped at the old disabled conditional decision and not the new one that was created. (The screenshot above is the old conditional branch before creation of the new one). The odd thing is that we created a copy of the document and ran the copy through the workflow process and it proceeded as normal. Is this expected behavior? We noticed that it took longer than usual for the workflow to run on the copy and noticed that there were over 100k activities logged for one instance. (Am not sure if this is why it is slow to process) .

Thank you, 

0 0
replied on November 13, 2019

It sounds like you're saying this is part of a larger workflow. It's not really possible for us to guess what might be happening from the description provided. If you're still seeing the old activities being executed, then likely you updated a running instance. In that case, the behavior is expected: only activities after the currently executing one would be updated, and if you have large loops, then all contained activities are considered running for these purposes.

But again, there's not enough information to troubleshoot.

 

0 0
replied on November 13, 2019

Thank you for the insight, yes this is a part of a larger workflow. The original issue was that the documents would stop at that conditional branch even though the field was filled in (we viewed the metadata and it was filled) , all documents were stopping at this branch even though the field was not empty. They had a similar issue with a different workflow but it was fixed by disabling the conditional decision, creating a new conditional decision, then republishing. Unfortunately, all documents that were running the old workflow had to be deleted and taken through the process again with the "new/republished" workflow, in order to be processed. Hopefully that clarifies some things. Thank you, 

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

Sign in to reply to this post.