You can do it with a little bit of work.
There is a function called CurrentUser. This function is equal to the username of the person currently logged in through the Workgroup. (Don't jump up and scream yet.)
If you really don't want to play too many games with user groups and stuff, I don't blame you. It isn't my call that you think it isn't worth the investment. But this is what you have to do in order to avoid that investment.
Every query that a person could directly open (we are talking only using "canned" queries here) must include a reference to a text field in some table that is set up to hold the logged-in username. When a new entry is made in the table that holds usernames, it must be marked with the appropriate name. Then, when the person later runs a canned query, the query must include a criterion of [StoredName]=CurrentUser
Now, you suggested that folks get their stuff by region. So that implies a region table. If your canned queries ALWAYS do a join with the region table, then perhaps the only place where the username has to be stored is in the region table. If not, then you might have a problem with redundancy.
This does not take into account that a person might attempt to do an ad-hoc query that doesn't include a join to the region table and the username criterion.
If you don't like storing the username in your regions table, then consider storing a table with only username and a code number, but then store the code number in every applicable table. Then join these tables to the username/id table and use the criterion of [storedusername]=CurrentUser. This simplistic approach assumes that regions don't overlap, so that the relationship between username and region is effectively one-to-one. It gets more complex (though not much more complex) if that is false, because of the possibililty that a person might have more than one code entry in the table that maps user's ID to region.
Nowhere in the above did I take you into user groups, nor did I delve too deeply in VBA. So this should be eminently usable. Remember, you CAN use functions in queries. Don't be afraid to do so. Just be aware that some queries, if they return enough data, might run a little slower because of the function.
The only way to stop THAT... is to make your FORMS have a hidden control (property .visible = false, .locked=true) that has a default value of =currentuser, then make the form's selection include a reference to that invisible, locked control. That way, the user's name must only be evaluated once. But this DOES make the form a little bit harder to manage.
For what it is worth, I don't think I would have designed a solution that involved WorkGroup security, either. That would be a wrong usage for security. What I might have done, though, was to use security make general database items inaccessible to ALL folks you want to use this method of access. Give them (as a group) access to the forms, queries, etc. In this case, you would have to read up on the .OwnerAccess property as a way to let a user run a query on a table to which he has no rights to open directly. When you get to this depth, you are usually getting deeper into VBA and putting intelligence into the forms.
