authorizations by activity and business processThe run time authorization mechanism works as follows: Authorization via roles Roles can be linked to the following model items: You must first define the roles in the Roles (tgbrg8110m000) session for the current modeling version before you can link these roles to any business process or activity. All the roles that are linked to a business process are inherited by all the activities within that business process. A role that is linked to a business process or an activity in the repository, is inherited by that business process or activity in the business model. Example Activities B, C, and D are incorporated in business process A. Business process A represents the highest level in the business process structure. The other activities, which can also be nested business processes, represent the lower levels in the business process structure. Roles:
The manager is responsible for all business process activities except activity D. The secretary is only responsible for activity D. You can define the situation in the example as follows:
Linking of roles After you have imported the roles, you can link additional roles to the business processes and activities. These roles are incorporated in the business model, and do not apply to the these same business processes in the repository. In the Enterprise Model Browser and in the Enterprise Modeler Editor you can view which roles are linked to the business processes, and where they were linked (repository or business model). Use the following sessions to link one or more roles in the repository: Use the following sessions to link one or more roles in a business model: Authorization via responsibility codes You can define the responsibility codes in the Responsibility Codes (tgbrg8130m000) session in the master data. If you link a role to a business process or activity you can specify a maximum of six responsibility codes (responsibilities) for that role. The business process and/or activity to which the role is linked can be carried out by an employee if at least one of the responsibility codes linked to the role is set to YES. If the role has no responsibility codes, the role is always active. The responsibility codes that are linked to a role are inherited by all the activities within the business process to which the role is linked. Example This example is the same as the one for the role authorization, except that in this example the responsibility codes are also involved. Activities B, C, and D are incorporated in business process A. Business process A represents the highest level in the business process structure. The other activities, which can also be nested business processes, represent the lower levels in the business process structure. Roles:
Responsibility codes:
The manager is responsible for all business process activities except activity D. The secretary is only responsible for activity D of which must be reported to the manager. The manager checks activity D as soon as the secretary has carried out this activity. You can define the situation in the example as follows:
Authorization for Application type activity If you link a role to a business process or an activity you can also define the authorization for that role for activities of type application. Authorizations:
Linking employees to roles If you have defined the roles, the next step is to link to each role the employee(s) that must fulfill it. Carry out the following steps to link employees to roles:
| |||