AWF Actions during Wait-Evaluate Loop
I have an application (A). A is enrolled in Advanced Workflow, and after a series of actions/layouts/etc., the users select an AWF action to move into a "monitoring" phase. In the AWF, the monitoring phase consists of a "Wait for Content Update" node (B) and a "Evaluate Content" node (C). At this phase in the AWF, users have no direct access to the fields used in the content evaluation, as the evaluations are based on complex calculations involving related records in a separate application (D), which are controlled by a separate set of users. As such, periodically, the node B will timeout and forward to C, C performs The series of checks against A, and if all fail, then C defaults back to B. Eventually, calculations should result in a path that forwards to a new "User Action Node" (E) with a new layout and purpose. So far, this all works. I have two problems.
1) I'd like to have multiple paths from C, where more than one path returns to B (looping transitions). Unfortunately, when I do this, upon any successful evaluation, B seems to stop timing out, never again forwarding back to C. Is this possible?
2) Is it possible to present an AWF action (button) to allow users to escape the loop and branch to an alternate (previous) node? I'd like for users to be able to move back to a previous layout and enter information before resuming the loop.
It's possible that I'm going about this all wrong, so I'm open to alternative solutions. I'm simply trying to avoid users having to perform manual monitoring of the records and making decisions that can be completely automated.
I'm currently running 6.6, but am in the planning stages of moving to 6.7.
- Advanced Workflow
- Community Thread
- Forum Thread
- Generalized Content
- RSA Archer
- RSA Archer Suite
- Specialized Content
Caveats: Please correct anything I have misinterpreted.
a) Your AWF hits the eval node (C) first
b) The transition from eval node (C) to Wait (B) is the default. This insures that any True evals go out the proper path. You can set a specific rule on the default, but I find it better to test for positives, that way if the data matches true it flows through and doesn't hit the Wait node at all.
1) The Waiting node is behaving as expected. Once you have a true eval, the Eval node would never go back to the Wait node. The Wait Node is actually now doing anything except pausing for the set time. So the eval node does all the heavy lifting.
1.a) In my testing I couldn't create a second transition from the Eval to the Waiting node. I'd appreciate knowing how you did that. I could find some uses.
1.b) Your best fix for multiple evals and loops to B would be to add a series of Evals/Waitings (you can use the same layout for each Wait node, but you need different nodes) based on the different conditions.
2) You can't add "buttons" to Waiting nodes.
2.a) You could add an escape field that users can mark and then Save the record. That will force the record through the Eval node. At that point you can eval the escape field and send them to a User Layout that is locked except it has "buttons" to all other layout nodes. You can lock the buttons down so that only people can only go to the specific layouts they are allowed to go to.
In 6.6 and above SysAdmins see all buttons. Make sure to test with a non-sysadmin account to eval if your transition permission are working as expected.
I'll try to clarify:
a) AWF hits the Wait node (B) first. Is this not the intended construction?
b) Transition from eval to wait is the default.
c) multiple "true" paths exit the eval. Some contain backward transitions that return to the wait/eval loop after several steps.
2) This is pretty much what I expected. I had considered adding an "escape field" but found this to be very kludgey, and was hoping for something better.
1) It seems that the expectation is that a wait/eval loop is only ever traversed once. If I have a backward transition, and it ever hits the wait node a second time, then the wait node never times out a second time.
Wait nodes are generally built in conjunction with an eval node, with your path hitting the eval node first (use a what are you waiting for rule). Think of a wait node as a timer node. It is just going to wait a preset time and then pass the record to the eval node. If it evals true the record moves on, otherwise back to the Wait node.
The other way a Wait node fires is through a manual save, which then sends the record to the eval node ....
You can use a Wait node more than once BUT it will only go through a single Eval outbound.
From a design perspective it is easier to just add more eval/Wait node combos where you need them.