You cannot put one precondition directly after another I'm afraid. You can do that with decisions, so maybe that is what you were thinking of? My general thought would be to put a pre-condition after the status in the task process concerned which looks at the status of the parent change. Then have an automatic action which does what you need it to do (complete?) if the parent status reaches a certain point. The process engine should reevaluate all these sorts of conditions when the status of the parent process changes. There are limits as to how many of these pre-conditions followed by automatic actions that you can use in any one process, but it should be fine for the case you have described.
So in your example:
The "To Build" status is the status that the Change goes into after an approval has been done and then you want it to automatically route based on the action that was selected?
Am I understanding this correctly?
It looks as though you could have a Condition in the process that checks the statuses and routes accordingly. In your task just have a Completed/Approved status and a Rejected/Retired status and then created the condition to check against that.
1 of 1 people found this helpful
Thanks for the input. I have moved on a bit and forgot to update the request. I not have a precondition checking the status and if true (ie status = build), then an autoaction (The infamous "dummy") and then two preconditions which will direct the RFC accordingly. It will sit there in "dummy" status until a task tells it to move on... case closed!
Now all I need is the syntax for the calculated condition which I think is wrong ( I need to reference Change/Status/isEnd.)
Process Designer stops you from savings if you have two preconditions triggering automatic actions as you have setup.
Presumably done by LANDesk for "process self preservation" reasons and it doesnt matter if the preconditions evaluate to mutually exclusive outcomes either.