With ADDT, you could create your DB management page based on a table or a recordset. If you chose the recordset, the criteria for the recordset was maintained throughout the process, whether it was a url value, post value, or session value. It was not sophisticated enough to handle joins in recordsets, but you could have more than one criteria, and the generated pages kept track of that criteria so that those filters were still available when you came back to the results page.
Session values will work, but you still have to handle the cleanup so that those values are not still in use if you arrive on the page by other means. Session values do work and that is one of the ways I handle this with the current extension. The other is to see that the url values are preserved through hand coding on the generated pages. If the generated pages could be based on a recordset, the amount of hand coding goes down.
Session values have some draw backs at times. If the user does not travel the path you expect, session values from a previous action can collide with a new action because the cleanup process was bypassed.
WA Server Validation can do this. If the user returns a server validation error; abandons that process; then comes back to the form for a different process, the validation values from the previous attempt get filled into the form. For that reason, I always clear them at the end of the form unless I have a specific reason to preserve them. I wish clearing them was the default behavior because I generally do not need to preserve them after the form is populated from a failed validation.