It's not clear how you are using that global field to specify search criteria. Several scenarios come to mind, but none "quite fit" what you describe.
You might consider a find script patterned after the examples found here: Scripted Find Examples
Then a "modify the search" option can be just returning the user to the search form where they see the global fields with the values used in the previous search.
I realize my previous post was a little ambiguous. I have a database that contains scripts - the theatrical kind, not the computer kind. Each record represents a different page in the script. One job of the users of this database is to identify topics of conversation found on each page of the various scripts. There are several hundred scripts and thousands of pages. Likewise, the list of topics referenced within all these scripts is rather massive. In order to maintain consistency throughout the database, the global field "Topics List" is just that - it lists every identified topic of interest from all of the scripts. The user can then copy/paste any applicable topics on that single page of the script from the "Topics List" global field to the "Topics" field. This master Topics List could easily be located outside the database in a Word document, but we decided to use a global field so users wouldn't have to switch from one program to another. The master Topics List is not the field that is intended to be searched. If the user wants to find a script page that references a particular topic, they would start a search, copy/paste the specific topic from the Topic List to the Topics field and then perform the find. When the search is executed, the global field Topics List reverts to the very top of the list, so if a user wanted to then refine the found set of script pages by another topic, they would have to do a lot of scrolling in the Topics List field to get back to where they were - is there any way to keep the Topic List field from reverting back to the very top of the field after performing a search? This question is less about searching and more about field behavior...
Putting multiple rows of data into a single field is usually not the best approach to use. This sounds like you need a table of records with one topic for each record in the set of related records. You might, instead of copy pasting, just link the current script page record to a specific Topic record:
Start with these relationships:
ScriptPages::__pkScritpPageID = Page_Topic::_fkScritpPageID
Topics::__pkTopicID = Page_Topic::_fkTopicID
You can place a portal to Page_Topic on the ScriptPages layout to list and select Topic records for each given ScriptPages record. Fields from Topics can be included in the Portal to show additional info about each selected Topic record and the _fkTopicID field can be set up with a value list for selecting Topic records by their ID field.