Check for Visibility in the Organizational Model The check of authorization object CRM_ORD_LP makes it possible to control access to transactions, depending on the employee's assignment to certain organizational units via his or her position.
The following options are offered:
Own sales organization (and the underlying organizational units)
Using the position to which the user is assigned in the organizational model, the related sales organization is determined in the sales scenario. The user can also be assigned to multiple sales organizations. The system then checks whether the transaction that the user wants to process was entered for this sales organization or for one of the lower-level organizational units assigned to the sales organization. If this is the case, and the user has the authorization for his or her selected activity, then he or she can process the transaction.
Own service organization
Using the position to which the user is assigned in the organizational model, the related service organization is determined in the service scenario. Several service organizations can also be assigned. The system then checks whether the transaction that the user wants to process was created for this service organization. If this is the case, and the user has the authorization for his or her selected activity, then he or she can process the transaction.
Own sales office (and the underlying organizational units)
Using the position to which the user is assigned in the organizational model, the related sales office is determined in the sales scenario. Several sales offices can also be assigned. The system then checks whether the transaction that the user wants to process was entered for this sales office or for one of the lower-level organizational units assigned to the sales office. If this is the case, and the user has the authorization for his or her selected activity, then he or she can process the transaction.
Own sales group (and the underlying organizational units)
Using the position to which the user is assigned in the organizational model, the related sales group is determined in the sales scenario. Several sales groups can also be assigned. The system then checks whether the transaction that the user wants to process was entered for this sales group or for one of the lower-level organizational units assigned to the sales group. If this is the case, and the user has the authorization for his or her selected activity, then he or she can process the transaction.
Own distribution channel (assigned organizational units and their underlying organizational units)
Using the position to which the user is assigned in the organizational model, the related distribution channel is determined in the sales scenario. Several distribution channels can also be assigned. Then the system checks whether the transaction that the user wants to process was entered for this distribution channel or for an organizational unit to which this distribution channel is assigned, or for one of the lower-level organizational units assigned to this organizational unit. If this is the case, and the user has the authorization for his or her selected activity, then he or she can process the transaction.
Higher-level node
Using the position to which the user is assigned in the organizational model, a node one level higher in the hierarchy is read in the organizational model. Then the lower-level organizational units and business attributes subordinate to this node (sales organization, sales office, sales group, distribution channel, service organization) are determined. The system then checks whether the transaction was entered for one of the attributed organizational units. If this is the case, and the user has the authorization for his or her selected activity, then he or she can process the transaction.
This also applies for two to ten higher-level nodes, that is, a node up to ten levels higher in the hierarchy is read in the organizational model, depending on the position assigned to the user.
This check has the advantage that you do not have to explicitly enter the organizational units for which each user should have authorization, in their user profile. Furthermore, when the user is reassigned in the organizational model, the new assignments have immediate effect on the authorization check, as the check is always carried out dynamically at runtime, and the relevant organizational units are not fixed in the authorization profile.