This page is meant as a placeholder for questions about KEW functionality by the KRA group.
1) Ad-Hoc Routing: When you ad multiple users or workgroups to an ad-hoc route, do they visit them in parallel or in serial?
Since there's no explicit way to define how an action request is activated... it's determined by the node set on the ah-hoc request. If the node is sequential the priority used by the new ad-hoc request is 0 so it should complete the ad-hocs before the others in the route path i would think. Eric can confirm when he's back from vacation.
(Eric Westfall) That sounds right to me.
2) Ad-Hoc Routing: Does "return to its prescribed path" mean that the action for the user initiating the ad-hoc request/s is removed from their action list until all ad-hoc requests complete, at which point it returns to their action list? How does this work?
My best guess is that 'return to it's prescribed path' simply refers to fact that once the ad-hoc requests are satisfied the routing will return to what it was prior to the ad-hoc's being added. Now it's kind of misleading because the ignore previous and the new always see/never see future requests stuff will take into account ad-hoc requests as far as i remember. But i am fairly certain sending ad-hocs does not remove the current routing until the ad-hocs are complete.
3) What is a focus channel? - not defined in glossary?
This has since been removed and the entry for Route Log no longer discusses a 'focus channel'. I believe the orignal meaning was meant to convey that the Route Log was originally always a pop-up window as opposed to taking over the screen of document search/action list. The idea of 'channel' came in to play because KEW had it's own portal page with a 'channel' main page.
(Eric Westfall) This was just some outdated terminology in our glossary I think. The term 'focus channel' was a concept within the IU portal (Onestart)
4) The Move action, implies that logic can exist in the node after an action request has been deactivated, that then allows the current node to be set to some other place in the workflow? What is the function and limitations of this? Can you move across parallel paths, for instance?
This is one Eric will definitely have to confirm but i believe you cannot jump parallel paths. You could return the document to a previous level before a split and then send it back down the other side of a split but that would probably have to be worked out in some custom attributes. I believe the 'move' action was also set up to be used by documents if they say wanted to skip over levels and such. To move a document past a level during an action request deactivation is probably more complex than can be done. A custom node class could probably call a move though.
(Eric Westfall) Yeah, if you are on one branch of a parallel path you can't really jump to a different branch. Essentially it lets you move backward and forward in the route path. The easiest way to think of it is both "Return to Previous" and "Blanket Approve" rolled into one. Since a return to previous is essentially a move backward and a blanket approve is essentially a move forward.
4) approvePolicy seems to control whether one person in a group or all people in a group need to approve, however the documentation seems to indicate that it is only applicable to roles. Is it also applicable to workgroups? If not, can you specify whether you only need one approval from the workgroup vs. all the members to approve?
Currently the approvePolicy is not applicable to workgroups. It's something we would like to do for future enhancements and there may even be a Jira issue already but it's not done yet.