The Authorization Concept for Working with Records Management
The authorization concept for working with Records Management has three levels. Level 1 is checked first, followed by level 2, and then level 3.
As a general rule: An authorization check for an element in its own repository is only successful if these authorization checks are successful (for example, for business objects, the authorization check for displaying a business object in the current application must be successful).
Level 1: Authorization restrictions for defining views
Prerequisite: User roles have been defined. The views are each assigned to one or more users.
Creating views in the Records Organizer
The administrator can create a role-based view and assign it to a user role. The role-based view contains element types and elements that users with that role need for their everyday work.
The role-based view is designed to simplify user navigation from the initial screen. If no role-based view is created, the user will see all the element types that exist in the current
RMS, and would have to use the Search activity to display each individual element.Creating views in the Records Modeler
When creating a record model, the administrator can determine for which roles each node is visible. When users create a record using a record model, only the structure nodes, model nodes, and instance nodes are displayed that have been defined as visible for their role. The user can therefore only create elements for element types that are assigned to the visible nodes.
Controlling views in the Records Browser
In a record, a user can determine which nodes are visible for which roles. This is valid for model nodes that do not yet have any elements, as well as for nodes that have elements assigned to them, and structure nodes.
Level 2: Authorization check using the Records Management authorization object
The general authorization object for Records Management is called S_SRMSY_CL. This applies to all elements within Records Management, and has the following authorization fields:
You can use the fields to restrict the authorizations within an authorization object. As soon as you enter a value, the authorization is restricted to this value. If you do not want to set any restrictions, enter ‘*’. You can enter more than one value for each field.
This authorization check is carried out before the user performs the following actions:
For every element type and every element that is displayed as a node in the list, the system checks whether the user has authorization for the current RMS, the element type (SPS ID), and the Output activity.
If the check is failed for an element or an element type, the node for the corresponding element/type is not displayed in the list.
For the activities Search, Display, Information, and Log, the system checks whether the user has Read authorization for the RMS and the element type of the element.
For the activities Create, Edit, and Delete, the system checks whether the user has Write authorization for the RMS and the element type of the element.
If this check is failed, a message is displayed stating that the user does not have authorization to execute this activity.
Level 3: Authorization check using authorization objects of the individual service providers
Service providers can implement their own authorization checks. This authorization check is called in connection with the authorization check of the general Records Management authorization object. For service providers that do not implement their own authorization check, level 3 is omitted.
The following service providers supplied by SAP have an implemented authorization check:
The service providers named above are all based on the same back end; the generic service provider. The authorization check for all these service providers is therefore identical. For more information, see
For more information, see
The Authorization Concept for Circulars and Process Routes.