Hi Matt, Thanks for the response! Actually I am doing a Person.setAddresses(listOfAddresses) when the Address details page is submitted. This sets the list of addresses for the Person in the nested conversation not affecting the parent conversation. The reason is that Seam has taken a snapshot of my Person entity in the outer conversation on nesting (which didn't have the new addresses). The original Person instance will be reverted back to should the user back up to the original edit Person screen and submit. Seam retrieves the outer conversation by id on submit and restores the state of my Person object at the time of the snapshot which doesn't include the new addresses. I hope that clarifies the scenario a little bit... You bring up an interesting point with respect to the EntityManager. I will have to test this point using the Seam managed persistence context. I do not know the effects of nesting on the Seam managed persistence context and whether it is included in the state snapshot. Currently my implementation does not require a Seam managed persistence context as we always perform a fetch join when dependent objects are needed and merge() on final submit. Thus, I am keeping my entities within the scope of the conversation context. This ensures that nesting the conversation will maintain a state snapshot of my entity in the outer conversation context regardless of changes to the entity in the nested conversation. Maybe an expert on the effects of nested conversations on a Seam managed persistence context could shed some light on this? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085669#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...