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

Question

Question

workflow looping

asked on May 6, 2014

 Good Afternoon,

 

We have designed a workflow for a client who wants to use a multi value field to track each person who "touches" a document. The "assign a field value" called "History Tracker"  is called when the document is originally created and assigned the token %{initiator}. Then each time the document changes, it is supposed to add the name of the next initiator via the "assign a field value" "History Tracker.".

 

The issue is that we are getting a loop effect. the client must have each initiator listed in the multi field as they "touch" the document.

 

Any suggestion on how to circumvent the looping issue ?

 

Attached are the starting rules and the workflow. The invoke workflow simply moves the document to the next user selected.

 

Regards,

Brian

 

 

Capture 1.PNG
Capture 2.PNG
Capture 1.PNG (11.98 KB)
Capture 2.PNG (41.54 KB)
1 0

Replies

replied on May 9, 2014

Just as an FYI, if you find yourself always adding conditions to your starting rules that prevent the Workflow user from kicking of workflows, you might consider using the User Exclusion Filter.

 

1 0
replied on May 12, 2014

This is a good tool for that, but I want to make one addition. If you use the exclusion filter you are telling the subscriber never to evaluate changes by that user, so that would also prevent your workflow user from being able to satisfy wait conditions. Usually this is acceptable, but it is something to be aware of.

2 0
replied on May 6, 2014

I'm not sure what you mean by looping issue. How I understand your usecase:

 

You have a class of documents that whenever they are changed you want the user responsible for that change documented in the history field.

You do this by having a workflow start based on entry changes in the specified folder.

The workflow appends the initiator (changer) into the history field.

 

You next invoke a workflow to route it to the next user, though I'm not sure how it is finding who the "next" user is.

 

If you could give me some more information on the "looping issue" and how the invoke is being called and what you want it to be doing I can probably help you.

0 0
replied on May 7, 2014

Hi Brian,

 

You will have to add to your rule trigger to prevent the workflow from starting if the user is your workflow user.  What's happening is your initiator is touching the document which will trigger the workflow, as intended.  However, when workflow adds the initiator's username to the multi-value field, it is technically "touching" your document as well, which will cause the workflow to trigger again.

 

To prevent the looping, add to your workflow starting rule:

 

User Does Not Equal <workflow account>

 

For <workflow account>, enter the user account that is in the connection settings for your workflow.

replied on May 9, 2014

Hi Matt,

 

Okay, let me walk you through the scenario as it should be performing.

 

1. A user creates a document.

2. The workflow process will assign the %(initiator) value into a multi-value field called History. The initiator in this case shall be called User1, who is also the person who created the document.

3.  User1 uses a field called "Route To:" to route the document to another user we shall call User2.

4. User2 makes some kind of change to the document and saves it. The "History" field should append User2 to the filed list.

5. User2 uses a field called "Route To:" to route the document to another user. (and the process goes on and on.)

 

 

What is happening:

 

There is a workflow rule that looks for a change to a document in a folder with a specific template and field selection

 

We are using the object "Assign Field Value" to assign the %(initiator) value to the "History" field. Whenever the workflow sees the change caused by the "Assign Field Value" it restarts the workflow because of the change... and it continually starts a new workflow session.

 

The attachment shows the workflow.

 

Regards,

Brian

 

0 0
replied on May 9, 2014 Show version history

So the change of assigning the field is starting a workflow?

It looked like in the screenshot the rule was excluding your workflow user from starting the workflow, so maybe check that the user you excluded is the user workflow is using to make the changes.

 

If that does not solve it check out the subscriber tracer to see what exactly is making the rule succeed:

 

 

 

Another alternative:

If you are routing the document around and when wait conditions are satisfied you add the field, you can handle the assign field value in the original workflow. Use the %(WaitforEntryChange_User Name) token.

2 0
replied on May 12, 2014

Hi Brian,

 

It looks like the above responses answered your question! If one of them did, please click the "This answered my question" button on the post.

 

If you still need assistance with this matter, just update this thread. Thanks!

0 0
replied on May 15, 2014

Hi Kelsey,

 

While all of the input has been helpful, none have been a solution.  

 

Were these workflows to use a "wait for entry change", the issue would not exist, but they do not need the documents to sit "in the wild" for what might be weeks at a time, so they have the route to process occur whenever someone picks a person to route to. Thus every time the document changes, its going to cause the undesired results.

 

The only solutions that have been suggested by anyone I've talked to both here, and externally, are to: 1. remove the "Assign Field Values" object, or have the client use Audit Trail. This would be fine except they wanted a quick visual indicator for random audits.

 

Regards,

Brian

0 0
replied on May 15, 2014

As to the "sit in the wild" issue, I don't understand what the issue is there. It does not hurt your workflow server to have long running workflows or wait conditions, so that solution seems fine to me.

 

So as I understand it, the issue is that when a user sets the "route to" field that is an entry change that gets logged and starts the workflow, where you only want to log the changes by the person being routed to.

 

My ideas:

You can put in conditions to check if the initiator is the user in the "route to" field.

Make sure to clear the "route to" field when you assign someone to the history field, so that another change will not start that workflow until there is a new user to route to.

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

Sign in to reply to this post.