As with most software solutions, there are generally several ways to achieve the same result. One method would be to use the protect and read protect rules for each attribute or process conditionally based on the loggedinusers access level.
A method that I typically use is to control the visibility of the link or button to the operation (i.e. 'add meeting') in the same way.
Both of these solutions are managed in the config tool, not at runtime but I think that you would be able to use either method with a little thought to make the operation accessibility conditional on elements that you control at runtime which is the scenario that your screenshot shows.
To have flags in an individual users profile in order to conditionally control that users 'functionality' is easy. In order to streamline it so that you are working with access levels rather than individual users, I would create a permissions BO with yes/no attributes to control the various operations, and a text attribute with the name of the access level. You can set these with defaults originally but allow admin to modify the yes/no values. Then use a rule or process at runtime to link each user to their respective permissions BO based on their access levels. Now you have a method to control operation access based on access levels but managed at runtime. (LoggedInRegularUser.Permission.AddMeeting='Yes')
Note that you can apply the same approach to visibility of menu items such as an 'Add Meeting' menu item, based on the users access level.
Good luck,
Pete
