It's all about the answers!

Ask a question

Workitem approval changes workflow state?

Dan Sevcenco (5021923) | asked May 04 '13, 2:27 p.m.
I am writing an advisor that is responsible to decide whether the save operation can be allowed based on the state of all the approvals that exist in the workitem.

Upon debugging the code, I noticed something strange to me. When the approver closes an approval and saves the workitem, the workflow state for the oldstate and new state show that the server thinks a workflow state transition is about to take place, even though the state of the workitem has not been changed by the user.

Why is RTC behaving like this? This behaviour is throwing off my validation logic that says that if the workflow state is not changing, the advisor does not need to do anything. How do I compensate for this?

3 answers

permanent link
Ralph Schoon (63.2k33646) | answered May 05 '13, 4:49 a.m.
 Dan, the process configuration can be set to change the state of a work item on approval. This might be configured and cause what you see. You can configure it not to do that however.

permanent link
Dan Sevcenco (5021923) | answered May 05 '13, 11:06 a.m.
Hello Ralph,

I know of that possibility and it is disabled in my case. I did a bit more debugging and this is what I found:

- on the first attempt to save the item after an approval is closed by the approver, RTC returns the next state of the workitem on the workflow as being "state.s2".
- on a 2nd attempt to save the workitem, after the first attempt is rejected by the advisor, without making any changes to the workitem, the same RTC returns the next state of the workitem as being "state.s1".

I wonder why is it doing this and how on earth am I to compensate for this behaviour in order to make the right decision in the advisor?


Dan Sevcenco commented May 05 '13, 1:41 p.m.

OK, please strike my answer. I figured it out.

Ralph Schoon commented May 05 '13, 1:44 p.m.

What did you find? 

Dan Sevcenco commented May 06 '13, 3:28 a.m. | edited May 06 '13, 3:45 a.m.

It was a mistake a made due to the fact that I do not know RTC well enough, yet. Basically, I forgot that I had attached state transition rules to the work item workflow and the observed behaviour did not trigger in my mind the link to the cause.

The pre-defined behaviour of RTC's would have worked very well if not for the fact that my work-item has to have several approvals that are all closed before a state transition can be allowed to take place.

permanent link
Dinesh Kumar B (4.1k413) | answered May 05 '13, 11:16 p.m.
have you tried the precondition "Required Approvals" which does :
        "Verifies that a work item can only be saved if all required approvals are in the configured state."
You can reach it through:
Open PA in Eclipse Client > Process Configuration Tab > Team Configuraiton > Operation Behavior > Work Items > Save Work Item (server) > under specific role > Preconditions > Add Required Approvals > Work Item Type > Select specific state and Edit Approvals

Dan Sevcenco commented May 06 '13, 3:33 a.m.

I know of that precondition. However, it does not exactly map to the business rules that need to be automated in order to properly manage this workitem type.

I have several approvals that need to be processed by different people in different organizations. The owner is changed automatically each time an approval is closed to transfer the workitem responsibility and accountability. And only after all the approvals are closed, a workflow state transition can be allowed, depending on the approval decision.

Your answer

Register or to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.