"petemuir" wrote : Surely you will have lost all the data associated with the pageflow at this point (e.g. any updates to entities will be lost) so the pageflow would have to start again? I agree. However, shouldn't the data from previous steps be saved in the database (I'm not doing anything with transactions to delay saving) automatically by Seam. But beyond that, what I'm looking for is the ability to specify an action method to execute instead of the no-conversation-view-id. I am using the no-conversation-view-id now and redirecting to an action in pages.xml which executes an SFSB method and then returns an outcome for a new *.xhtml page. However, it would be a lot better and more contained if I could just specify the action in the pageflow definition itself - similar to the no-conversation-view-id. Right now I am just restarting the pageflow in the pages.xml action. However, for the right pageflow process, the SFSB method called could be smart enough to "setup" the conversation state (and entirely up to the developer to make sure the state was restored correctly). The example I am working through is a shopping cart checkout process. If the user is on page3 (e.g., filling out the credit card info) and they get distracted and leave the computer for an hour, the conversation on the server times out (or maybe the server got restarted). Then, I currently send them back to the beginning (which is to login) of the pageflow using no-conversation-view-id. However, my pageflow is such that I could "restart" the pageflow if I could call a method that would load the Cart from the database which in this usecase would be all that is required to re-initialize the SFSB state. I would then like the last node to be displayed (in this example page3.xhtml). Ideally I would display some type of FacesMessage and the data would be populated on the form based on what they submited. Now the user would have to re-enter the information on page3 and submit; but they do not have to re-do the entire pageflow up to that point. Some might argue that the user should have to login if they have not be active for a period of time. I agree; but this time period is longer than a conversation timeout. And then what about server reboots - albiet that is probably an edge case that hopefully doesn't occur very often - but all the edge cases is what makes programming interesting. Just some food for thought, --jc View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964107#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...