With authorization, you can restrict users from viewing confidential data on-screen or deny them access to certain transactions. For instance, suppose your company has two departments, each supervised by a different manager. Your business process demands the user of one department cannot view the salary structure of the other. Alternatively, the person running a cost report is shown only the costs incurred as a result of activities performed in his or her own division.

Basically, SAP decides at runtime whether a particular user is permitted to enter a given application area. While a thorough description of authorization is beyond the scope of this article, it’s a good idea to familiarize yourself with the inner workings of the authorization mechanism.


An authorization is simply defined as a set of assigned values for each authorization field of a given object. Authorizations are first created and then assigned to users via authorization profiles.

Authorization objects and fields
Before you can provide checks in your programs, relevant authorization objects must exist. An authorization object is composed of a number of authorization fields that represent the smallest component against which authorization checks may be programmed. The fields of these objects may be used to restrict the access of the relevant user. Each field has a certain number of values. The list below shows some of the standard authorization objects common in human resources:

  • P_PCLX         HR: Clusters                              
  • P_ORGIN       HR: Master Data                           
  • P_ORGXX      HR: Master Data – Extended Check          
  • P_PERNR      HR: Master Data – Personnel Number Check

Authorization profiles

An authorization profile is a group of authorizations that collectively form a generic representation of a job role or description, such as an HR payroll user. All authorizations are switched off for a user upon creation. The system administrator then assigns authorization profiles to user master records. A particular authorization profile may be assigned to multiple users. Likewise, a user may be allotted multiple profiles, each covering a different job role.

Using the AUTHORITY OBJECT statement is essential to writing even the simplest authorization checks in your ABAP programs. You may use this statement in conjunction with other ABAP statements to check the user’s permissibility within a particular application area. This statement is effective only if the relevant authority object exists. The syntax is as follows:
            ID fieldname1 FIELD fieldvalue1
            ID fieldname2 FIELD fieldvalue2
            ID fieldname3 FIELD fieldvalue3.
             If sy-subrc eq 0.   “Authorization exists

When using the command above, you need to specify an authorization object along with the fields (fieldname1, fieldname2, etc.) and their comparison values (fieldvalue1, fieldvalue2, etc.). For field names that are unimportant from the authorization perspective, use “DUMMY” as the field value. SAP conducts a check by comparing the values passed by the programmer with those entered in the user’s profile. If the user passes this authorization check, the return code SY-SUBRC is set to 0. An example is shown below:
            ID RELID FIELD ‘RX’   ” Cluster RX of payroll data
            ID AUTHC FIELD ‘R’    ” Read authorization
            If sy-subrc eq 0.   “Authorization exists

The authority object PCL_X is used to check for authorizations of clusters residing in tables PCL1, PCL2, and so on. We specify the comparison value of the cluster name (RX) in place of field RELID and the operation (R—read) to be performed on the cluster data. If the relevant authorization for the user is found in his or her profile, the field SY-SUBRC is set to 0.

Code samples
When you come across a standard program, search for the AUTHORITY OBJECT command to get an idea of the authorization objects that are used. The following are a few of the ways this command can be used to control the application behavior based upon the user’s profile:

Disabling or hiding screen fields
The AUTHORITY OBJECT command is first used to determine the authorization of the user. If SY-SUBRC is set to a value other than 0, the loop is executed. The loop disables all the fields having group1 equal to ‘DAT’. In case the user is authorized, the loop is not executed (since SY-SUBRC would be 0) and the fields are shown enabled.
Authority object ………….
    if sy-subrc ne 0.
          Loop at screen.
              If screen-group1 eq ‘DAT’.
                    Screen-invisible = 1. 
                   Modify screen.

Disabling Menus or toolbar buttons
You may use the SET PF status …. EXCLUDING statement to disable certain functions on an application screen.
    Authority object ………….
    if sy-subrc ne 0.
                   EXCL_TAB = ‘INS’.
                   Append EXCL_TAB.
               SET PF-STATUS ‘ABC EXCLUDING EXCL_TAB.              

In case SY-SUBRC is not equal to 0, the functions that the user is to be deprived of are selected and populated into the table EXCL_TAB. Then the SET PF-STATUS command is used to display all functions except those included in the EXCL_TAB table. If authorization occurred, the code would not execute and the internal table would be empty. This would display all functions enabled to the user.

In report criteria
Users may try to view data pertaining to unauthorized areas by entering certain inputs on a report’s selection screen. The coding that deals with such a problem is shown below.
     Select * from bkpf .
 Authority object …………
    If  sy-subrc eq 0.
        Write : /…………

In this case, the authority check may be placed inside the select loop. Data that is read from the database is passed to the authority check for determining the permissibility of the current user. The WRITE statement is executed only if the return code is equal to 0 (i.e., the user has authorization of the relevant BKPF field).

Use what you already have
Mastering authorizations is essential to implementing any module of SAP. You should always follow some simple rules: Whenever you’re given a standard program, try to find an authorization object that is already being used, and ask the system administrator to set the user profiles according to your requirements. Also, when developing your own applications, try to use standard objects already provided by SAP. Finally, always consider developing your own objects as a last resort.