Process Flow of the Authorization Check in Business Transactions

Business transaction processing in SAP CRM is protected by an authorization check based on alternatives, so that only authorized users can create, change, display, or delete a transaction.

The authorization check follows a specific sequence, that is the check runs through several levels. This means that authorization can be granted at each level, and therefore no check is necessary in the subsequent levels. If for example, an employee is in a transaction as the employee responsible, he or she is allowed to process this transaction, regardless of whether further checks would lead to a positive or negative result.

The authorization concept in the CRM business transaction has the following characteristics:

Role-related protection
Users have access to existing business transactions, regardless of all other authorization checks, if they have been entered as a partner in these transactions. This can be an example of a user-defined partner function; the user does not need to have the Employee Responsible partner function.

You can control the type and scope of the permitted activity, (for example creating or changing transactions), for each partner function and partner function category.

See also: Partner Processing
Sales area/relationship in the organizational model
Users have access to new or existing business transactions in or below a certain level in the organizational model, regardless of all other authorization checks. If necessary, users can execute only specific activities.
Business transaction category
Users can create transactions only if they have authorization for the corresponding business transaction category (for example, activity - CRM_ACT, opportunity - CRM_OPP).
Business transaction type
Users have access to activities only if they have authorization for the corresponding business transaction type. If necessary, users can execute only specific activities.
Sales area
Payment card processing
Only authorized users are able to see the payment card number.

Prerequisites

Users for whom an authorization check is to be executed must be assigned in the organizational model.

Recommendation

To execute other functions, for example partner determination, we recommend that you assign an employee to the position, to whom a user is assigned in the business partner record.

End of the recommendation.

Process

The authorization check is run according to the following procedure:

This graphic is explained in the accompanying text.

Your own transactions (authorization object CRM_ORD_OP)
The system checks whether the user in the relevant transaction takes on a specific partner function for the activity executed, for example, whether he or she is the employee responsible. Furthermore, the system checks whether the user has the authorization to change, display, or delete a transaction. If the result of this check is positive, no further checks take place at transaction level.
Visibility in the organizational model (authorization object CRM_ORD_LP)
If the user is not authorized in the first step of the check, the second check is carried out. This check makes it possible to control the access to transactions, depending on the employee's assignment to certain organizational units via his or her position. This authorization object defines which transactions can be processed by the user in the individual organizational levels, and which activities he or she can carry out here. If the user is authorized for the chosen activity (create, change, display, delete) and the relevant organizational level, no further checks are carried out.

Note
When maintaining the authorization field CHECK_LEV, you should choose only the organizational unit at the highest level of the units to be checked. If, during the authorization check, the system checks the relation to a specific sales organization for example, the organizational units beneath this are also automatically checked. This means that you do not have to choose the (lower-level) organizational unit sales office. This would cause considerable deterioration in performance.

End of the note.

For more information, see Check on Visibility in the Organization Model.
Territory check (authorization object CRM_ORD_TE)
If the business transaction for which the system performs the authorization check belongs to a business transaction type for which the territory check has been activated, the system determines the territory of the business transaction in question. For more information about the territory of a business transaction, see Territory Determination in the Business Transaction. You activate the territory check in SAP CRM Customizing for Customer Relationship Management under Transactions Basic Settings Define Transaction Types .

The system then determines in which territories the user (for whom the authorization check is being performed) is authorized to perform the selected activity, by the CRM_ORD_TE authorization object (authorization object CRM Order - Visibility in Territory). CRM_ORD_TE can authorize a user in his or her own territories only, or both in his or her own territories and in any territories below this. If this includes the territory of the business transaction, the user is authorized for this business transaction, and the authorization check ends here. However, if the user's CRM_ORD_TE entries do not include the territory of the business transaction, or if CRM_ORD_TE does not grant the user any authorization for the selected activity, the system moves on to the next step in the authorization check.
Combination of several authorization objects
If the preceding checks were not successful, this combination of different authorization objects is checked. All the checks must be successful before the user is authorized to process the required transaction. This means that the user receives the authorization to process only if he or she is authorized to:
- Process the leading business transaction category in the corresponding transaction type
- Process the corresponding transaction type
- Process in the corresponding sales area
  1. Authorization objects CRM_ACT, CRM_OPP, CRM_SAO, CRM_SEO, CRM_CO_SE, CRM_CON_SE, CRM_LEAD, CRM_CMP, CRM_CO_SA, CRM_CO_SC, CRM_FM_FND, CRM_FM_FNP, CRM_FM_BPO
    Using these authorization objects, the system checks which business transactions the user is allowed to process, and whether he or she is allowed to carry out the functions create, display, or delete in these transactions. The system checks the relevant authorization object, depending on the activity executed:
    
    Activities: CRM_ACT
    Opportunities: CRM_OPP
    Sales transactions: CRM_SAO
    Service transactions: CRM_SEO
    Service contract: CRM_CO_SE
    Service confirmation: CRM_CON_SE
    Lead: CRM_LEAD
    Complaints: CRM_CMP
    Financing contract: CRM_CO_SA
    Sales contract: CRM_CO_SC
    Fund: CRM_FM_FND
    Funds plan: CRM_FM_FNP
    Budget posting: CRM_FM_BPO
  2. Authorization object CRM_ORD_PR
    Using this authorization object, the system defines which action the user is allowed to execute for each business transaction type.
  3. Authorization object CRM_ORD_OE
    Using this authorization object, the system defines in which sales area or in which service organization the user is allowed to process CRM business transactions, and which activities he or she can carry out there.

If the user is not authorized in this step of the check, he or she is not able to process the transaction in the required way. The user receives a system message that contains the corresponding authorization object, and refers to the lacking authorization.

Effects on the User Interface Layer

When selecting the transaction to be created, only those transaction types of the business transaction categories for which the user is also authorized, are displayed. For example, if you only have authorization to create opportunities and sales transactions, only the transaction types for the Opportunity and Sales business transaction categories are displayed.
Function keys Create/Change and Delete: The system displays only the keys that the user is authorized to use. If, for example, you are only authorized to display, the key Create/Change is not active.