"tom.baeyens(a)jboss.com" wrote : That is why i would put them on one page. On top you could have a radio button to specify what you're looking for: process definitions, process instances or tasks. "tom.baeyens(a)jboss.com" wrote : You could have one search page as described above. You might for instance start from that page and get a list of process definitions. Then for each process definition there might be a link called 'search process instances'. When clicking that link, you could navigate to that same search screen with process instances already selected as the items to search for and also the selected process definition prefilled in the criteria. Well I guess that is assuming that the process name, and I guess version, is enough to uniquely identify a process definition, but that doesn't really seem to be the case from looking at the database schema. Or maybe there should be an ID field for each type of entity to search, so that a specific entity can be unambiguously selected. However, if for example you have the ID of a process instance, you don't need to also specify terms to select the process definition, so this would add the possibility for several different combinations of invalid search criteria. Also, I don't like the idea of one big search page, just because it's either going to be somewhat to implement (lots of javascript), or complex for the users to use (think bugzilla's massive ugly search page), or possibly both (either way we're talking much more complex queries). To me, a list of radio buttons with javascript to modify the search page is no better than separate links going to separate pages. If it were purely a question of reusing HTML, I could just compose pages using the facelets templating stuff. I'm really concerned that the queries will become more complex to build and test, and slower to execute, as the number of joined tables increases. By having separate seach pages that work from the context of a single parent object, the queries can be simplified to search a much smaller set of tables. For example, "from ProcessInstance where processDefinition = :defId and startDate = :start" rather than "from ProcessInstance pi inner join pi.processDefinition pd where pd.name like :name and pd.version = :version and pi.startDate = :start". In general my philosophy is: the simpler, the better. Does this make sense? "tom.baeyens(a)jboss.com" wrote : * (Re)binding process states to specific sub process definitions. | * Checking the size of the logs | * Migrating process instances or process definitions to another db | * Avg tx time | * ... Ok, that's fair, I did not know about those. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975503#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...