Previously, all authorization objects were treated equally by the Authorization Robot. However, this approach led to some problems with the practicality of the calculated roles.

Applications as leading authorization object

Basically, SAP authorization objects can be distinguished between applications, such as transactions or services, and other, mostly subsequent authorization objects. Applications represent a complete or partial business process and therefore have a particularly high priority in an authorization concept. All other authorization objects are always related to an application and specify the scope and manner in which it can be used. For this reason, the applications are regarded as the leading authorization objects in the Authorization Robot. This approach allows several important practical aspects of SAP systems to be taken into account.

Run and update capable roles

In SAP, the authorization default values for applications can be maintained using transaction SU24. Correct maintenance means that the correct authorization objects can be proposed immediately in the PFCG. The Authorization Robot also considers the authorization objects proposed in SU24. All authorization objects required by an application are therefore also available in the corresponding role later on. The specification of the corresponding authorization objects is based on the usage behavior of the users who then are to receive this role. This mechanism ensures that each role is functional on its own. Furthermore, in the event of an SAP update, the calculated roles can be updated at any time without having to rely on the Authorization Robot. Once a role concept has been calculated, it can be maintained and extended manually. Furthermore, the interpretation and understanding of the calculated role concept is significantly simplified.

Purity of application component

The SIVIS consulting team ensures the purity of the application components when creating the single roles in SAP. In concrete terms, this means that a single role may only contain applications from a single application component. This criterion is considered by the consultants in all their projects. For this reason, single roles calculated by the Authorization Robot are also built according to this rule. Thus, the resulting single roles form small, functional units that relate only to a single application component. Single roles are then combined in composite roles. Thus, composite roles can also contain different application components.