Derived and Composite Role

Derived Role

·     Derived roles refer to roles that already exist. The derived roles inherit the menu structure and the functions included (transactions, reports, Web links, and so on) from the role referenced. A role can only inherit menus and functions if no transaction codes have been assigned to it before.

·     The higher-level role passes on its authorizations to the derived role as default values which can be changed afterwards. Organizational level definitions are not passed on. They must be created anew in the inheriting role. User assignments are not passed on either.

·     Derived roles are an elegant way of maintaining roles that do not differ in their functionality (identical menus and identical transactions) but have different characteristics with regard to the organizational level.

 

Composite Role

·     A composite role is a container which can collect several different roles. For reasons of clarity, it does not make sense and is therefore not allowed to add composite roles to composite roles. Composite roles are also called roles.

·     Composite roles do not contain authorization data. If you want to change the authorizations (that are represented by a composite role), you must maintain the data for each role of the composite role.

·     Creating composite roles makes sense if some of your employees need authorizations from several roles. Instead of adding each user separately to each role required, you can set up a composite role and assign the users to that group.

·     The users assigned to a composite role are automatically assigned to the corresponding (elementary) roles during comparison.