DFCON & ORGPD – Auth Switches

My apologies if the title of the post make no sense. Probably that’s because of the relatively niche nature of the topic. However, in the last few months, I have come across a few installations where people have run into issues due to security configuration around access to non integrated positions (the so called default position) and thought a new post might be in order.

Both DFCON and ORGPD are authorization switches (refer to my post on Authorization Switches for some background) which control how your SAP security system handles access to employees with non integrated positions (these are the people who exist in the HR component but are not linked to any positions in the Org Mgmt Structure). Setting the proper values for these switches is an one time activity when configuring Structural Authorizations in your SAP system. Since structural authorizations use the OM structure to control access to employees, its a valid question “How do you want to control access to EEs/Pernrs which are not part of the OM structure?” These authorization switches help answer the question. The screen below shows a view from transaction OOAC using the switches.

OOAC - DFCON and ORGPD Switches
OOAC – DFCON and ORGPD Switches

Note that both these switches control access to non integrated persons but shouldn’t be used at the same time. Use ORGPD switch when using plain vanilla structural authorizations and DFCON when using the context solution. There is also a slight difference in the meaning of the different values possible.
Access to these non integrated persons can be controlled by the value of the Org Unit stored in infotype 0001 (org Assignment). However if there is no org unit also maintained in the infotype, the system provides the option of giving/ denying access to all these persons. These two different cases are highlighted in the below screenshots from IT 0001.

Org Assignment - Default Position with no Org Unit
Org Assignment – Default Position with no Org Unit
Org Assignment - Default Position with Org Unit
Org Assignment – Default Position with Org Unit

Possible Values for ORGPD/ DFCON and their meaning

1 = Check access to Org Unit maintained in IT 0001 for persons not linked to the OM structure. if no values are maintained in IT 0001, deny authorization to the person.

2 = Do not check access to Org Unit maintained in IT 0001 for persons not linked to the OM structure. Deny access to all these persons.

3 = Check access to Org Unit maintained in IT 0001 for persons not linked to the OM structure. if no values are maintained in IT 0001, give authorization to the person.

4 = Do not check access to Org Unit maintained in IT 0001 for persons not linked to the OM structure. Give access to all these persons.

0 (ORGPD) = Structural Authorizations are switched off. So the check for pernrs not present in OM doesn’t arise.

0(DFCON) = Same behavior as maintaining 1 for DFCON with one important difference. Context solution is activated by switching on one or more of the INCON, XXCON, NNCON switches which in turn activates authority check for the P_ORGINCON, P_ORGXXCON or the custom Z object. I would explain with an example, For DFCON = 1, INCON = 1 you would need an authorization with P_ORGINCON with all values * (PROFL, PERSA, etc) to get access to pernrs with default position and no org unit maintained. For DFCON = 0, INCON = 1 you would need an authorization with P_ORGINCON with PROFL value * to get access to pernrs with default position and no org unit maintained. PERSA need not be *.

Context Solution

In the modern enterprises, its very common that dual responsibilities are performed by the same individual. For example a Line Manager in the Training department of an Organization needs access to certain infotypes (like org assignment, personal data, education, etc) for all employees as part of the process structure. In addition to the above, by virtue of his position in the org hierarchy as a Line Manager, he would also need significantly more access (like basic pay for instance) to the employees who report up to him. This is problem of contextual security and is can not be handled properly through the structures that we have covered so far.

Let us investigate further about the possible security solution in this case and try to understand why it might not meet the full requirements. We would need at least two roles for the training manager – on role with training infotypes and a second one with infotypes needed by the line manager. Further we also likely to have two PD profiles as well – on with access to all employees and the other with access to only the direct reports. When the 2 structural and general authorization profiles are assigned to the same person, like to the Training Manager in our discussion, we find that he has access to both sensitive and non sensitive infotypes for all employees. The sensitive access is not limited to only the direct reports as the security system has no way of understanding that access in the manager role needs to be restricted to only the direct reports (the people who are part of the manager PD profile).

The context solution introduced as part of SAP R/3 4.7 seeks to address this very gap in HR security. The context solution introduces new authorization switches and the corresponding authorization objects. To switch on checks for any of the new objects, the corresponding switches should be set to 1. Its also customary to switch off checks(value 0) for the non context authorization objects. The relevant switches are given below

  • AUTSW-INCON HR: Master Data (Context) for object P_ORGINCON
  • AUTSW-XXCON HR: Master Data – Enhanced Check (Context) for object P_ORGXXCON
  • AUTSW-NNCON HR:Customer-Specific Authorization Check (Context) for customer specific authorization object. The switch corresponds to AUTSW-NNNNN (HR: Customer-Specific Authorization Check) in the non context solution.

In addition to the three switches above there is a fourth switch used by the context solution. This last switch – AUTSW – DFCON – HR: Default Position (Context) – is analogous to ORGPD switch used in normal structural authorization as it controls access to non integrated personnel numbers (persons who are on a default position and as a result are not mapped to the organizational structure).

The fields for the individual authorization objects P_ORGINCON and P_ORGXXCON are given below.


Authorization Field Long Text
INFTY Infotype
SUBTY Subtype
AUTHC Authorization Level
PERSA Personnel Area
PERSG Employee Group
PERSK Employee Subgroup
VDSK 1 Organizational Key
PROFL Authorization Profile


Authorization Field Long Text
INFTY Infotype
SUBTY Subtype
AUTHC Authorization Level
SACHA Payroll Administrator
SACHP Master Data Administrator
SACHZ Time Recording Administrator
SBMOD Administrator Group
PROFL Authorization Profile

You will notice that new authorization objects differ from the corresponding old objects in a single respect. Both of these have the new field PROFL (Authorization Profile). The PROFL field is meant to store the value of the PD profile for which each general authorization is valid. In other words, the PROFL field serves to link the general authorization with the corresponding structural authorization. Context problems, like the one we discussed about the Training manager, can now be easily solved by maintaining the correct PD profile on the role.

The context solution is truly a welcome addition to the other security features of SAP HCM as it allows us to solve scenarios which couldn’t be solved with the means at our disposal till now. However it comes at the cost of increaded maintenance effort as now in addition the PD profiles assigned to the user, we need to maintain the correct PD profiles for the role as well. Also, we should remember that the context solution only addresses the context problems for accessing people (PA master data). There is still no context solution for PD data secured through PLOG.

PD Profiles – Performance

In a large organization using structural authorizations, the PD profiles assigned to a user might return thousands of distinct objects. Evaluating the entire PD profile at run time to generate the object list, for each access to HR data, can lead to a significant degradation in performance of HR transactions. Since the performance penalty is mostly due to the evluation of the entire object list for an user during run time, the situation can be improved by storing the list of objects for a user.

SAP provides a table T77UU to store a index of all objects returned by the PD profiles for each user. However, since this is a static list of the objects we have to periodically regenerate the index for all user who are maintained in this table. If a user is not entered in this table, his PD profiles are evaluated at runtime to generate the object list. This will consume more time but will not adversely impact performance if the number of objects for the user is below a certain critical threshold.

The T77UU table is very rarely maintained manually. SAP provides two programs, RHBAUS02 – Check and compare T77UU (user data in SAP memory) and RHBAUS00 – Regeneration of INDX for Structural Authorization, to automate updation of the table and regeneration of the user indexes. The screen below shows, the selection criteria for the RHBAUS02 report. The report can be run for one or multiple users and for a certain threshold level of HR objects. The program evaluates the PD profiles for all the users entered in the selection screen and if the number of authorized objects returned is more than the threshold value updates the user in the T77UU table. Conversely if the number of objects for a user falls below the threshold, the user entry is removed from the T77UU table. Typically , a weekly batch run should be sufficient to take care of changing org structure and the profile assignment for users.

RHBAUS02 - Update user data in SAP memory
RHBAUS02 - Update user data in SAP memory
The RHBAUS00 program is generally run after the last run for RHBAUS02 has completed and hence finished updating entries in T77UU. The RHBAUS00 program re-generates the indexes, and hence the objects authorized for a user, for all users entered in selection whose entries also exist in T77UU. In a practical scenario the OM structure of an enterprise keeps changing from day to day. Since, the index only stores the objects that were effective during the last time when it was re-generated, RHBAUS00 should be scheduled to be run periodically. A daily batch run for the program is mostly sufficient to take care of the changing org structure however even in such cases, indexes of individual users might need to be specifically regenerated through the program or its linked tcode, S_PH0_48000110.
RHBAUS00 - Regenerate user INDX
RHBAUS00 - Regenerate user INDX

PD Profiles – Assignment

PD profiles can be assigned to users in two basic ways

  • Transaction OOSB can be used to assign one or more PD profiles directly to users. Adding entries to the T77UA table through SM30/SM31 has the same effect.
  • OOSB - Assign PD Profiles
    OOSB - Assign PD Profiles
  • PD profiles can also be assigned to OM objects like positions through infotype 1017 (through transactions like PP01/PP03).
  • PP01-Create PD Profile for Position
    PP01-Create PD Profile for Position

    Also note that an user without an entry in the T77UA table would by default have the PD profile access which is assigned to the SAP* user in the table. SAP provides a standard program RHPROFL0, to read the PD profile values from IT 1017 for a position and create an entry in the T77UA table for the user assigned to the position. For SAP installations using indirect assignment of profiles, this program is generally scheduled to run in batch every night. A screen with the various options available for this program is shown below.

RHPROFL0 - Tranfer IT enttries to T77UA
RHPROFL0 - Tranfer IT enttries to T77UA
    Assigning the PD profiles to the position instead of direct assignment in the T77UA table can potentially save a lot of effort in manual maintenance of profile entries and is the recommended practice.

PD Profiles – Definition

PD profiles are created through the OOSP transaction. SAP provides a few standard profiles but to a large extent, PD profiles are created by individual customer depending on their requirements.

OOSP - PD Profiles
OOSP - PD Profiles

The definition of PD profiles is stored in the T77PR table. Lets have a look at the definition of the standard PD profile for “MANAGER”

T77PR - PD Profile Definition
T77PR - PD Profile Definition

Some features to note about the definition of the PD profile.

  • Each record in the table is independent of the other records and gives access to a certain number of objects.
  • Each record has values for PV (Plan Version), OT (Object Type ), Object ID, EvalPath (Evaluation Path), StatV (Status Vector), Depth, M (Maintenance Flag), Selection Period and Function Module.
  • PV denotes the plan version for which the profile is valid.
  • OT is the object type of the object id value.
  • Object ID gives the start object when an evaluation path is used in the profile or an individual object.
  • If evaluation path is maintained, the PD profile returns the object along the PD profile. maintaining an evaluation path will only work if a start object value is maintained explicitly or dynamically through Function Modules.
  • Status Vector is used to determine the status of the objects/relationships while creating the structure. A StatV of 12 for example will consider relationships of status Active (1) or Planned (2).
  • Depth determines the level of the hierarchial structure till which the evaluation path is constructed. No maintained value indicates that the entire org structure returned by the evaluation path will be constructed.
  • Maintenance(M) flag determines whether a person will be able to maintain the returned objects.
  • Period determines the validity period of the objects/relationships while creating the structure. A value of D creates the structure which is valid on that day. A blank value indicates that the structure is not limited by the validity dates for the corresponding relationships.
  • The function module field can be used to dynamically generate a start object. Efficient use of this option can greatly reduce the maintenance effort for PD profiles. Two standard function modules are supplied by SAP, RH_GET_MANAGER_ASSIGNMENT returns the org unit for which the user is a chief while RH_GET_ORG_ASSIGNMENT returns the org unit for a user. New function modules can be created by customers as per requirement.

Structural Authorizations

Structural Authorizations as the name suggests are used to restrict access to a certain organizational structure. As such they are only used while accessing HR data. In general, structural authorizations serve two purposes

  • Restrict access to certain OM objects like Org Units, Jobs, Tasks, Qualification Catalogs etc.
  • In interaction with the access to authorization objects for PA master data, they can restrict access to certain set of persons in the enterprise.

While using structural authorizations, its important to note that

  • A person’s total authorization is a result of the interaction between his general authorizations (through roles) and his structural authorizations (through PD profiles).
  • Secondly, structural authorizations are always used to restrict access. You can never use structural authorizations to grant access. It can only be used to restrict access to a smaller set of objects or people than is already given though a general authorizations.
  • While using structural authorizations to restrict access, we need to ensure to add access to the corresponding objects are also added to the user’s roles through PLOG.

Since we have already extensively discussed, security roles and their assignment we will use the next few articles to describe PD profiles and their assignment.

Evaluation Paths

An Evaluation Path is a chain of relationships between related OM objects in the Organizational Hierarchy. Different evaluation paths can be used to return different sets of OM objects even when all of the individual paths start from the same start object. As such, evaluation paths are used in a lot in OM reports and in structural authorizations.

Evaluation Paths are created/maintained through the transaction OOAW shown below. The standard SAP system ships with a number of pre-defined evaluation paths. Since the standard evaluation paths can only use the standard relationships and objects defined in SAP, it stands to reason that we need to create new evaluation paths to use our own relationships/OM objects.

OOAW - View for Evaluation Paths
OOAW - View for Evaluation Paths

As an example we select the evaluation path PERSON and see how its defined

OOAW - Define Evaluation Path
OOAW - Define Evaluation Path

The PERSON evaluation path is meant to return the OM objects used in staffing along a standard organizational hierarchy. As such it can be used to evaluate the reportees of a line supervisor and is used as such in the MANAGER structural profile. The definition of the evaluation path starts with an org unit. The path returns all positions (S) assigned to the start org unit (O) and the persons (P) linked to the said positions. Finally to build the entire org hierarchy the path continues to evaluate the sub-ordinate org units and positions (lines 30 and 40).

Once defined, the evaluation path can be used to return a particular view of the org hierarchy through the PPST transaction.

PPST - Evaluation Options
PPST - Evaluation Options

The report output shows the evaluated objects.

PPST - Report Display
PPST - Report Display

In the next article, we explore the use of evaluation paths in defining structural authorizations or PD profiles

Organizational Management

This article about organizational management is meant to be a launchpad to our discussion on structural authorizations– an unique and indispensable part of HR security. We ave already have had a brief idea on Org Mgmt or OM when talking about the PLOG authorization object. Lets take the discussion forward to the next level.

OM deals with the representation of the personnel organizational structure within an enterprise within SAP HCM. OM uses the same data model as used by Personnel Planning. The data model uses object-oriented design and uses the concepts of

  • Object Types
  • Relationships
  • Infotypes

The data model can be represented by the following graphic. Note that object types, Person and Cost Center are shown as orange boxes instead of blue ones. These are External Objects and not created in the OM component. However, they have relationships with normal OM objects.

OM Data Model
OM Data Model

A typical org structure when represented by the same data model might look something like the graphic (transaction PPOC) shown below

PPCO - Org structure showing positions and org units
PPCO - Org structure showing positions and org units

In OM, each element in an organization is represented by a distinct object with individual characteristics. Relationships are used to link one object to another. The objects and their relationships can be created and maintained through standard transactions (like PP01). The network created by objects and relationships are flexible enough to facilitate personnel planning, projections and evaluations of the org structure. Customizing is used to enhance the existing object types or create completely new ones. Customizing also allows the creation of new relationships and maintenance of those relationships for existing or new object types.

Each standard object type is represented by a letter code (P = Person, O = Org Unit, S = Position, C = Job) while customized object types are represented by two letters like 9P. Relationships on the other hand are represented by a 3 digit code like 008 (belongs to), 012 (manages). Customer relationships are also 3 letters long but start with Z, like Z20.

The unique object id for an object type is stored in IT 1000 (table HRP1000)

HRP1000 - Positions
HRP1000 - Positions

while the relationship between two objects is stored in the IT 1001 (table HRP1001).

HRP1001 - Relationships for a position
HRP1001 - Relationships for a position

Finally, the org structure composed through these two tables is displayed through the PPOSE transaction as shown below

PPOSE - Org Structure Display
PPOSE - Org Structure Display