Organizational level ( org level in SAP ) is a very important field as far as role design is concerned. The basic concept behind having this in role design to have same value across all objects for a given role, unlike any other authorization field which can have different values across different authorization objects.
Certain fields which seldom have different values for different authorization objects are used as org level fields. Some of the commonly used org level fields are Company Code, Division, Sales Organization, Plants etc.
As we can see that org level fields can be maintained by “Organizational levels” button at the right top of pfcg-maintain authorization screen.
Based on the requirement, other non-org level authorization fields (barring a few exceptions) can also be converted into org level fields. Program PFCG_ORGFIELD_CREATE needs to be executed for this purpose. But this should be done only after thorough analysis because this step may impact several other roles as that authorization field might be present in many roles and once converted to org level, the value will have to be maintained via organizational level button for all those roles.
Some of the authorization fields which cannot be converted to org level fields are ACTVT (Activity), TCD(Tcode) etc.
As we saw that a normal authorization field can be converted to an org level field via program PFCG_ORGFIELD_CREATE. Similarly an org level field can be converted to a non-org level authorization field via program PFCG_ORGFIELD_DELETE.
Table AGR_1252 maintains roles to org fields values relationship. In this table we can find the org field values that have been maintained for a role.
Table AGR_1251 maintains roles to auth fields values relationship. In this table, we can find the auth field values that have been maintained for roles. One point to notice here is that for fields which are org level fields, we do not get any value in this table, but some alphabets beginning with $, e.g. $WERKS which means plant.
Earlier in this topic, we had stated that org levels are important because in some roles we need to have same values for some authorization fields across all authorization objects. So instead of maintaining this value individually in all objects, we maintain it only once at the top by clicking on “Organizational levels” button. When a field is defined as org level field, it acts as an org level field for all the roles where it is used.
Now let us assume a scenario where there is an org level field called plant ($WERKS). For all authorization objects where this field is being checked, we want to maintain the same value, except for an object (say XYZ) where we do not want this due to some security requirement. Suppose we want plant values 100 and 200 for all the objects, but for object XYZ we want to maintain only value 100.
Can this be done?
Because once we maintain plant values 100 and 200 at the top using organizational levels button, object XYZ will also get value 100 and 200 for field plant. We can achieve our requirement by applying the concept of org level breaking.
To apply only value 100 for object XYZ, we need to manually change this field.
There is a bit of caution involved here!
If we are dealing with master-derived roles, this will impact all the derived roles. Also any change in the org level values using organizational field button does not change value for this object in this role in future. Hence it should only be done when we are left with no other option. In fact it is not a good practice to break org levels, but in some unavoidable situations we are forced to do this.
As soon as we click the change button to maintain org field manually, we get the following information message:
As we discussed above that table AGR_1251 stores org level values with $ and some character (as $WERKS for plant values). But as soon as we break the org level for any object, AGR_1251 starts storing the “broken” numerical value which has been stored for that particular object. This happens because the relationship for that field in the object breaks with organizational level.
So table AGR_1251 can act as a “broken org level finder” in case we need to know in what all roles which org level fields have been broken. For this we need to put a filter for all the org level fields and check if any field is having non-“$” value.