Could it be that the records where this happen are locked (in use by another user?) We see this on batch scripts that run server side from time to time.
You an simulate network latency to try and duplicate the connection speed from the (very) remote office.
You may also want to install a packet monitor (EG wireshark) to see if packets are being dropped.
There is a phenomenon where script steps can be dropped if the network connection drops and restores. Sort of like this:
1) Client side requests to run script.
2) Script starts running, client side requests script step A to run with server hosted file.
3) Network connection is dropped while step A is being executed...
4) Client does not receive result of step A, but to try and continue gracefully, sends a request to perform step B to the server.
You can try and do some error trapping for results to try and proactively detect this, but FileMaker does not have a native way to detect dropped packets or connection state, aside from the hard failure of "lost communication with host".
The other obvious way to try and get around this is to detect for that far remote user, and have their scripts utilize "perform script on server" instead. This would also have the advantage of faster execution of the script, so free performance boost.
You might also want to verify that the contents of the global are properly set and that all steps are compatible with the client
how do they access with FMP14?
i have seen this only when connecting a FMP13 client to FMS14 and the ignored script step was a find - it was on all clients connecting with FM13 though.
The solution was to check if 13 clients are connected then the find needed to be called twice - only the second find was successful.
(the find actually retrieved a previously created record which happened through PSoS (server sided) and it appeared as the latency was that it was just out of sync ..)