Yes, global fields provide each user with their own "virtual copy" of that field so values set in such a field by one user are not visible to other users.
You can set up this kind of relationship between a single record table and table A:
LockTable::anyfield X Table A::anyfield
The cartesian join operator: X enables any record in table A to match to all records in LockTable and vice versa.
Now you can modify the value of a field in LockTable and if you use it in a "lock expression" in manage security, users that are not "full access" can be prevented from accessing and/or modifying data in this table until the value in the LockTable's record is modified to once again unlock the table.
I have created a new LockTable with a single Lock field, and created a relationship LockTable::Lock X TableA::tableAID. I then created some test scripts:
Show Custom Dialog ["Lock Status"; LockTable::Lock]
Set Field [LockTable::Lock; "Locked"]
Set Field [LockTable::Lock; "Unlocked"]
On my first test, I ran the 3 scripts on the server & all behaved as expected, but when I ran Lock Test on a client it did not return anything, & the other 2 scripts gave an error message that the server was modifying the record. I changed the Lock filed to global storage, and now the clients were able to run the set & clear scripts, but the status on the client and server are not the same.
Include a commit record after the set field step that modifies the record. Until the record is committed, the change in value is not accessible to other users and the record is locked against edits from other users.
Many thanks PhilModJunk - this has solved my problem.