The save find feature is user specific. If you want to create saved sets for everyone to use, then you can store them in a table. See if this thread helps.
The posted link saves references to the current found set. If changes are made to your data so that new records are created or existing records should/should not be included, these changes won't be reflected in this "saved set" approach.
An alternative is to capture and save the criteria an a table of related records. This takes a bit of work but it can be done.
Here's a general outline:
Script the find process so that the script....
Takes the user to a layout with nothing but global fields for entering find criteria.
Clicking find on this layout triggers a script that
Selects the appropriate layout
Enters find mode
Uses set field to move the criteria from the the global fields into the correct data fields
Set error capture [on] //Suppresses the "no records match" dialog if criteria fails to find at least one record.
Perform Find 
#Do whatever steps you need to sort and display your found records
Add a button for saving your criteria that uses Set Field to save your criteria in a set of matching fields in the related table.
Accessing a given "saved find" is now simply a matter of using a script to move the data from the selected record of saved criteria back into the global fields and then waiting for the user to edit the criteria further, just perform the find or to cancel....
I realize this is reviving an old thread, but I was searching for some information about this exact issue and this thread is what I found. I am trying to build a layout that allows a user to build a 'report' about a table. I want it to be flexible and have the option to save a search/filter, both to be able to re-use it themselves but also to share it.
I haven't dug much into FileMaker's Find abilities yet, but would I have to build a table to hold multiple lines of a more complex search criteria? E.g. if they want to search for 'author' who is "Bob" or "Sara". I am envisioning an interface where they can select a 'type' (e.g. author, title, date, etc) and then define the expression to search for, but allow them to build multiple lines of that. So kind of like adding a new 'record' to a table and then searching based on all of the records at once.
record 1) author "Bob"
record 2) author "Sarah"
record 3) date >2010
record 4) title "Filemaker"
These would all be keyed to a single search ID to keep them together.
This is actually very similar to Filemaker's own built-in Find ability where you add a 'new record' to create a new row of search criteria, but we want to be able to save them for future use and share them with others. So would I essentially be reinventing the wheel to do it the way above? But also, wouldn't it be required to do that in order to present the user with a save feature?
And about the table structure itself. I am thinking 4 tables...although I was just looking at it and I think it would be possible with 3. Maybe even two if the table of Globals isn't used. One for 'Sort_Criteria' holding the specific information for each line of entered sorting criteria. A second for 'Saved_Sorts' which would be the genesis of the foregin key for the Sort_Criteria table, but also contain user info. To get RID of a 3rd table you could just use a 'SAVE' flag in the 'Saved_Sorts' table. (I was originaly thinking of a 'Temp_Sorts' table that would hold the current sorts and then copy them over to the 'Saved...' table if that were chosen by the user.) But if we are always saving the Sort_Criteria lines anyway, it doesn't seem like I would need the table of Globals.
Then, there should be a script that could run periodically that would remove 'Sorts' from the 'Saved...' table that weren't flagged as 'Save...'. And then, of course, purge the 'Criteria' table at the same time. But if I use a 'Temp...' table I don't have to do clean up because I only save what I need. The 'Criteria' table would still need to be cleaned as it would have to be added to with each additional line the user added. Could clean up on exit from the layout. Would perhaps be nice to keep a log of the last 3 (5?) searches even if the user doesn't select to save them. They often may not think about saving the search right off the bat.
Just thinking out-loud, mostly.