If the multiple switchboards are separate forms, you have a bit of a problem. If they were tab controls on a single form, you have more a of chance to do it easier because all of the controls are in the same place. Then one event routine could evaluate who you are / what group you are in and just store that. But if they are different forms, you don't have that ability. Oh, well...
Basically, the way to enable or disable things based on who you are is to look at the form (Me, as a shortcut name in VBA context) to see the Users collection (which is part of each open form) to enumerate the Groups collection (which is part of the Users collection).
So look up Collections in the help files. They have some samples showing how to navigate the collections. The name of a user in the Users collection is Users
.Name; the name of a group in the Groups collection is Groups
.Name. Simple, eh?
Good security design suggests that you assign NO repeat NO rights or privileges according to who you are, but you DO assign group memberships. So Joe and Jim might be Managers, Sue and Flo might be Sales Reps, Bill and Judy might be Accountants, etc. You use GROUP membership to cause people to have rights and permissions.
The current user will be in the users group (See function CurUser in Help) and will allow you to find the groups to which that user belongs. Then your code can figure out what should be visible based on these groups.
Where would this go? In an event routine for each switchboard, perhaps. In the Form_Load or Form_Current event. I'm thinking that Form_Load might be OK since good security practices say you would require users to log off before they close the DB. So Form_Load, which occurs once per launch of a form, is adequate to evaluate security for the current user. (Now if you tried to allow folks to change users without first logging out of Access, that would be a very different story indeed...)
In the final analysis, you want to identify that the current user is a member of a group that is significant with respect to the switchboard. So that you can do all sorts of buttonnn.enable and buttonmmm.disable and so on and so forth in the _Load or _Current event code.
Now, this could be an if-ladder or a Select Case situation as to how you choose which items are enabled or disabled. I would write some subroutines that go through the controls and enable everything by using a For Each {control} in {the current form} - which is another example of traversing a collection of like objects. Of course, you have to decide whether the control has a Value before you can enable it. (If it doesn't have a value, it cannot be dis/enabled.) However, it might be easier to just look at the control type to determine whether it is a text box, check box, option group, etc. etc. and just enable or disable it if it falls into the right category. That is your call, not mine.
I'll add that it is sometimes hard to decide whether the control has a value because of the way Access defines sparse records or other items. You might not be able to see an items value for either of two reasons...
(1) No value is associated with the item because it is a static item like a label
(2) No value has as yet been associated with the item even though it could have a value.
