Why couldn't you have a script that runs (triggers) automatically every time the mechanic commits a new record of parts entered?
That was my first thought, but I couldn't figure out what the script would do.....i.e. how would it notify someone else that there was a new request. Wasn't sure what my options were (I'm fairly new to file maker & programming). My first idea was a popup window that would display to everyone logged into the database with a certain privilege set saying "New Part Request" that they could just see and then closeout of. I tinkered with the new window script, but it didn't seem to do what I wanted to.
I'd like to do this without creating another field, as this is a 1 table database. Tinkering a little more, I found the Insert symbols option, that seems to be close to what I want to do, I would just like it to show the total of records based on the criteria of the status field containing "New".
I'd like to do this without creating another field, as this is a 1 table database
That may not be a realistic expectation. FileMaker is a Relational database. It's true power cannot be tapped without linking tables in relationships and that almost always requires more than one table.
What we have here is a list of "ready for cashier" records that continually updates on computers operated by our cashiers. Other employees create the records and click a button to change the status to "ready". Those records automatically appear in the list and then disappear off the list when a cashier selects the tag, completes the transaction and prints a receipt for the customer.
That sound like something you could use in your system? (just think "new" instead of "Ready for cashier".)
I'm not opposed to creating another table, I just meant I only had 1 at the moment.
What you said about the ready for cashier is exactly what I am looking for.
I found a few articles after refining my search a little bit (one pertaining to the cash register example, one about push notifications and another using the ontimer script to open a custom window. I'm going to tinker around with some of those for a while....maybe I can make something work.
Here's what we use, though I'd probably have used Install OnTimer Script if it had been available in the version that we were using at the time I set it up:
Set Error Capture [on]
Enter Find Mode  ---> clear the pause check box
Set Field [YourTable::Status ; "New" ]
Perform Find 
Sort Records [Restore ; no dialog ]---> you don't need this step if you want to list the records in the order that they were created.
Pause/Resume Script [1 second]
This script starts up automatically when your users open the layout used to display this list. This creates an infinite loop so all buttons on this layout are set to either specify the "halt" option in button setup or perform a script that ends with the Halt Script script step to stop the looping.
I think I figured out something that will work
I created a new layout and when users of a certain privilege level open the database, it automatically 2 windows, 1 with the normal layout where they can edit records and another that looks similar but all the fields are locked from editing. Within this layout only an ontimer script runs to perform a find on everything with a status of new every 30 seconds. As new records are created, it automatically lists them out and as the records are updated to a status other than new, they drop off of the second screen.
Can you see any flaws in this that I may not realize? Im testing it right now and it seems to be working. I just wasn't sure if the constant perform find would cause any issues.
Under certain circumstances, (users are accessing via WAN instead of LAN, iOS clients, extremely large numbers of records in the table, summary fields, aggregate function calculations, conditional format expressions...) it might.
But as long as you keep your layout simple, host over a Local Area Network and not a Wide Area Network, I would expect it to work OK.