Either have a very wide and shallow flow structure where you set a variable indicating the next node to be displayed, you then use a split and join nodes to loop round this structure. It's the equivalent of the following pseudo code: 1. displayNode = "first" 2. switch(displayNode) 3. case first: Get answers displayNode = "second"; break 4. case second: Get answers displayNode = "third"; break 5: case third: Get answers displayNode = "done"; break 6: case done: Goto 10 Break 7: goto 2 10: finished. Obviously if the users doesn't fill in the answers but instead picks a different point display node would be updated separately. You can also do a similar effect with just plain rules where you have an object which determines the next rule to fire. Thomas ************************************************************************************** This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmaster(a)nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary. NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00 **************************************************************************************

Hi, Thanks for the answers. KiranP, I can't use what you have suggested because there can be some actions/customWorkItems in between asking questions. And we want to create a flow that business users can edit as well. For example if they want to change that for some specific answer for a question the flow should go to some other question or do some custom task or email customer they can just add etc. So we can't use dynamic flow that you suggested because in that case we'll have to define our actual question flow somewhere else may be a database. Any other idea? Thanks -- View this message in context: http://drools-java-rules-engine.46999.n3.nabble.com/Drools-Flow-Replay-tp... Sent from the Drools - User mailing list archive at Nabble.com.

As I see it, and how I might try to implement backing up: In the regular flow, the user is entering answers which will propagate the engine through the defined flow. Now consider saving these anwers and adding a simple mechanism that's capable of inserting this data into an engine in "start state" where nothing has been entered yet. This would bring the engine into the same state, right? So, to go back from step N to some step 1 <= x < N, simply use the answers 1,...x-1 to reach step x. You would have to implement some logic to decide what to do with the saved answers x+1,...N-1. If they are still useable, use the same replay mechanism to reach N again. -W On 20 August 2010 18:19, jawa <agohar(a)gmail.com&gt; wrote: