wschwendt, I completely understand your problem, but it seems that most of the posts I see about nested conversations are somewhat puzzling to me so I would like to hear some opinions on their usage. I have been using nested conversations in situations where I require a continuation server implementation. After a lot of thought, it seemed that this was the most logical usage of nested conversations given their state snapshot behavior. I have successfully implemented some very complex page flows with master-details editing relationships and all issues with the back button have been alleviated. The user is free to navigate as they please! The main issue that comes in with conversations is the master-details editing where the master controls the persistence of the data. For example, a Person and their Addresses: 1. Select Person for editing which displays a Person edit screen 2. Select Add Addresses which forwards to a secondary screen 3. Addresses are added and the screen is submitted which updates the in-memory Person 4. The Person edit screen is redisplayed with the Addresses added 5. The user then uses the back button to return to the original Person edit screen and submits which persists Person with new addresses If a single long-running conversation was used, you end up submitting addresses that were not intended by the user (at least not what they saw on the browser-cached edit screen) since the Person was updated in the conversation context. If the conversation is nested for the Address details screen, the addition of addresses does not affect the outer conversation. In other words, we have a snapshot of state prior to adding the Addresses. We do NOT end this conversation when the Addresses are submitted. Instead we continue the nested conversation on the new Person edit screen. Now, if the user was to back up to the original Person edit screen, the snapshot of conversation state is restored (the outer conversation) unaffected by the user's actions. If the user then submits, the state is persisted consistent with what the user "sees." By updating the outer (parent) conversation backing up to the original Person edit screen has the same effect as using a single long-running conversation. Data is persisted that the user did not intend. This is because we no longer have a snapshot of the browser cached state at that time. I hope this makes sense. If not, I can clarify. Thanks. ... By the way, a workaround in regards to updating parent conversation state you can always use a non-Seam POJO which maintains mutable state. Any class not annotated with @Name, will not be managed by Seam and thus, will not be reverted back to the outer conversation state when a nested conversation ends. All changes to the internal state of the object will stick in the outer conversation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085522#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...