Look at Customization Groups.  It allows you to set up panels by team, instead of one user at a time.

In Custom Office there is a "Hidden" check box for each field. 

I prefer to use inclusive or exclusive roles that do not have anything selected on the tabs, their only purpose is to allow you to identify users by common roles.  You can then use UI post load event scripts to check whether or not the user is a member of a role and HIDE, SHOW, ENABLE, or DISABLE controls based on any additional logic.  This cuts down on library customizations that have to be maintained during upgrades.  You would use the oSession.IsMember method and pass it a role name and it will return a 1 if the current user is a member of the role or a 0 if they are not.

UI scripts are difficult to get working correctly (triggers to handle tab clicks and loading new orders), with the possibility of Sage programming undoing the script logic, I tend to shy away from them, but if you have methods which work reliably, that is great.

Panel customizations are less finicky... because even if a field is not technically hidden, you can move it behind something else, making it invisible and unavailable to the user.  The limiting factor there is that a user can only have one Customization Group (where your script + Role strategy doesn't have that limitation).

Usually, Sage 100 logic will enable/disable OR show/hide controls but rarely both, so you just have to figure out which way you need to go about it.  These kind of role scripts usually work fine on just the UI post-load event if you pick the opposite of what Sage 100 does but if you need to, you can also use the table's post-read event but you need to filter for the UI and check the library using the UI object's GetScreenName to make sure you are only doing this for the appropriately task.  Which the oScript.SetUIControl method is suppose to intelligently handle controls so even if you pass it a control that doesn't exist, it should just ignore it.