Managing access roles
An access role rule defines a name for a role, and represents a set of capabilities. To deliver these capabilities to users, you reference the access role name in other rule types to assign the access role to users and to provide, or restrict, access to certain classes.
An access role identifies a job position or responsibility defined for an application. For example, an access role can define the capabilities of LoanOfficer or CallCenterSupervisor. The system grants users specified capabilities, such as the capability to modify instances of a certain class, based on the access roles they acquire at sign on.
An access group includes one or more access roles which define what the group can do. The same role can be used in multiple access groups.
When you create an access role, you can configure dependencies from other roles to determine access rights. Role dependencies are relationships between roles that can mirror an organizational hierarchy or more complex relationship between groups of operators, roles, or functional areas. For example, a manager should have all or almost all the access rights that a user has, plus some access rights that only managers have. An example of a more complex access relationship is an HR application. An operator can be allowed to create or modify a job position, set a salary, enter an interview evaluation, make a job offer, or run reports. The access rights in all these cases depend on the operator's department and level in the organization.
If you create access roles, be sure to create a last-resort Access of Role to Object rule at @baseclass for that access role, so that the class inheritance search always ends successfully.
Access role names have the format application name:role name, where application name is the name of your application and role name is the name of a role that uses the application.
Previous topic Dynamically adding roles during user authentication Next topic Standard access roles