The problems I see with this are as follows: * Having one single set of search criteria is more complicated than having separate searches. Initially I did do this. I tried to simplify it by having a select list where you'd select the type of search you wanted to do, and it would update the search criteria for the new search type, but this was much more complicated than the final search mechanism that i ended up with. By complicated, I mean complicated to implement AND confusing for the end-user. * We will need to keep track of where the user came from so they can easily return. Again this is doable in a couple of ways, but I think an overriding priority is bookmarkable URLs for pages, and this might compromise that. A bookmarkable URL implies statelessness, which would be complicated if we must track where a user navigated from at run time. For example, if I went from the Process page to find Process Instances, I'd want a link back to that process page to be right at the top. But if I bookmarked that URL, now that URL should contain something that indicates that you navigated to that search results page from the Process page. I think having a single search page is too confusing, unless you have an idea for how it can be laid out. We could however do (for example) one search page per result type, or use tabs to separate searches. The latter is tougher (but possible) to bookmark though. * View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999047#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...